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ABSTRACT 



An electronic Personal Information Manager (PIM) includ- 
ing a peer-'to-peer group scheduling/calendar system is" 
described. The group scheduling/calendar system provides 
methods for peer-to-peer group scheduling among users, 
including those users who only have simple e-mail support 
(i.e., do not have access to the group scheduling/calendar 
system itselQ. If a user is able to receive and respond to 
e-mail, he or she is able to participate in group scheduling 
in an automated fashion. Under user control, the system 
generates a scheduling invitation incorporating different 
formats. Each format includes, in order of increasing content 
richness, a simple text embedded sdieduling invitation, an 
HTML (Hypertext Markup Language) form embedded 
scheduling invitation, and a proprietary binary "MIME" 
(Multipurpose Internet Mail Extensions) scheduling invita- 
tion. Each format is designed to transfer the highest degree 
of information content which a particular target client type 
can handle. A recipient of the scheduling message employs 
the messaging format best suited for his or her environment. 
Regardless of which format the recipient employs, the group 
scheduling system processes the reply message 
automatically, with the appropriate information automati- 
cally inchided in the user's group scheduling calendar. The 
system supports different levels of participation of various 
individuals throughout various stages of group scheduling, 
despite the fact that some of the individuals who need to 
participate might use other proprietary software and reside 
in other time zones. 

36 Claims, 36 Drawing Sheets 
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SCHEDULING SYSTEM WITH METHODS 
FOR PEER-TO-PEER SCHEDULING OF 
REMOTE USERS 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records* but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to the area of 
information processing and* more particularly, apparatus 
and methods for managing and scheduling time-based infor- 
mation for multiple individuals located at different locations. 

Successful management of one's time is a goal that every 
successful professional must achieve. One's business day 
may be swept away in a deluge of meetings and 
appointments, all of which must be somehow managed. An 
attempt to manage this task on paper, such as with a simple 
wall calendar, is unworkable for all but the Amplest of 
schedules. More likely, such imsoptusticated aids to man- 
aging one's time will lead to scheduling conflicts, missed 
appointments, botched deadlines, and angry clients. 

Oftentimes, it is necessary to schedule a group of people 
for an event, such as a meeting. This is the problem of 
"group scheduling" — that is, notifying a group of people 
that a certain event is going to happen and receiving con- 
firmation from members of the group whether each can 
participate. Conventionally, "group scheduling" has been 
largely limited to scheduling events for users within a 
particular "work group.** Typically, a "work group*' has 
comprised those users connected together through a local 
area network (LAN). Alternatively, a **work group'* can be 
extended to users who can receive messages. In this 
extended group, however, manual processing on the part of 
the user is typically required. For instance, for a user who 
connects from a remote location, the user is required to 
manually process messages received to manually update the 
calendaring product to update one's scheduling status infor- 
mation. This leads to two disjointed activities for the user: 
(1) retrieving messages and (2) entering/processing sched- 
uling information. 

With the ever increasing importance of the Internet, work 
groups are no longer confined to local area networks, or even 
wide area networks (WANs). Instead, people are connected 
together via elecu-onic mail or ''e-mail." At the same time, 
however, users have become accustomed to the ease which 
automatic scheduling systems provide, such as those which 
operate within a proprietary environment (e.g., Novell 
Groupwise^ operating on a Netware® local area network). 
If users are not connected to the same proprietary system 
(e.g., Novell Groupwise), then the users must resort to a 
manual scheduling process. Here, the job typically falls to a 
secretary or administrative assistant who must contact each 
proposed participant individually, for determining his or her 
availability. Typically, the person charges with scheduling 
the event must "negotiate" with the proposed participants for 
reaching a time when the meeting can finally happen. The 
process is still not complete, however. A confirmation mes- 
sage must be sent to all proposed participants for confirming 
the final time. 

What is really needed are system and methods which 
permit any user to schedule appointments with a group of 



other users in an automated fashion, but without requiring 
the users of the group to employ or be coimected to a 
particular proprietary system. In particular, such a system 
shoukl allow a user to initiate a message to invite a group of 

5 people to a meeting (i.e., to schedule a meeting). Those 
individuals should, if they are able to receive electronic 
mail, be able to participate in the group scheduling. Here, the 
recipients need not have access to any particular proprietary 
software for participating in the group scheduling. Instead, 

10 each participant need only be able to receive and send e-mail 
(which can be done using a wide variety of products, from 
numerous vendors.) The present invention fulfills this and 
other needs. 

SUMMARY OF THE INVENTION 

15 

The present invention recognizes a user needs flexibility 
in choosing how appointments, events, and other time-based 
data are entered and managed; despite the fact that other 
individuals who need to participate might use other propri- 

20 ctary software and reside in other time zones. According to 
the present invention, therefore, an electronic group 
scheduling/calendar system is provided with methods for 
peer-to-peer group scheduling among users, including those 
users who only have simple e-mail support (i.e., do not have 

25 access to the group scheduling/calendar system itself), or 
even have no e-mail support. 

According to the present invention, if a user is able to 
receive and respond to e-mail, he or she should be able to 
participate in group scheduling in an automated fashion. In 

30 particular, the present invention allows a user to undertake 
group scheduling with other "remote" users located at 
different locations (including those with different time 
zones), regardless of what particular platform or software 
applications each of the other users is employing. In contrast 

35 to prior art scheduling approaches which required all users 
to operate the same proprietary scheduling software, the 
present invention instead requires only one user of a work- 
group to have the group scheduling software which the 
present invention is embodied. Every other user need only 

40 be able to send and receive e-mail messages — using any one 
of the wide variety of e-mail packages which are available — 
in order to be automatically tracked by the system. Still 
further, the present invention includes facilities for accom- 
modating even those users who carmot receive e-mail. 

45 "E-mail" itseff is a messaging-based approach which is 
exploited by the present invention for communicating with 
all users, regardless of which proprietary system a given user 
is employing. The present invention implements a messag- 
ing subsystem or exchange which provide scheduling primi- 

50 tives (e.g., "accept" and "decline" message types) for sup- 
porting the basic functionality of group scheduling, even for 
generic e-mail clients — that is, a client which does not share 
nor is even aware of the group scheduling software sub- 
system provided by the local client of the system of the 

55 present invention. This include ^dumb" remote clients 
which simply have no knowledge or understanding of the 
scheduling format supported by the group scheduling local 
client. 

In typical operation, for instance, group scheduling begins 
60 with a user scheduling an event, that is, sending to desired 
participants an initial meeting message or "invitation" for 
scheduling the event. The event itself can be any type of 
event, including those with a duration (e.g., meetings and 
appointments); "resources" (e.g., conference rooms, 
65 projectors, and the like) can also be scheduled. The recipient 
user(s) can receive the message across a variety of different 
software platforms or e-mail solutions. 
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The message itself comprises an identifier, such as <ISK> 
(or other unique), together with a scheduling invitation in 
different formats. The different formats include, in order of 
increasing content richness, a simple text embedded sched- 
uling invitation, an HTML (Hypertext Markup Language) 5 
form embedded scheduling invitation, and a proprietary 
binary "MIME" (Multipurpose Internet Mail Extensions) 
scheduling invitation. Each format is designed to transfer the 
highest degree of information content which a particular 
target client type can handle. A remote client having the 
scheduling system of the present invention can recognizes 
from the identifier that the message is from another propri- 
etary client. Accordingly, the client can process the binary 
''MIME" scheduling invitation natively. This message is a 
vendor-specific message, allowing direct, proprietary com- ^5 
municatioD between proprietary clients with the richest 
possible information content 

" Since otber clients have no knowledge of the sdieduling' * 
system, they simply ignore the identifier and the binary 
attachment To allow the local client to communicate with 20 
these recipient, non-proprietary interclient communication 
formats arc employed. For instance, a remote client with 
browser capability can employ the HTML form embedded 
scheduling invitation, which can be appropriately processed 
by its Web browser (e.g., Microsoft Explorer or Netscape 25 
Navigator); this represents the richest content that this client 
type can handle. The embedded HTML form (i.e., Web 
page) can easily be viewed by the Web browser as an input 
form having input fields corresponding to the information 
requested for scheduling the event. For instance, the fonn 30 
may include text or input fields for subject, time, event, and 
the like. Additionally, the form can include screen buttons 
for allowing the recipient user to "accept" or "decline" the 
invitation. At the conclusion of completing the input form, 
the recipient user can select "submit" for returning the input 35 
information back to the initiator. Here, the browser of the 
recipient generates a reply message, in a manner similar to 
that done today for on-line Internet registration. Upon 
receipt of the reply, the originating client can identify, 
decode, and process the reply appropriately. 49 

In the event that the recipient client is a simple e-mail 
client, the recipient client employs the simple messaging 
format incorporated into the scheduling message. Here, the 
recipient client can view a plain text e-mail message to 
which the user can respond (e.g., "accept'* or ''decline"). In 45 
the recipient client's reply, the client includes the "body" of 
the initial invitation message. As is common in e-mail 
communication, the reply message can itself easily incor- 
porate the contents of the original message. By simply 
including the initiator's original message when a non-SK 50 
client replies, the non-SK client is incorporating information 
which facilitates processing of the reply by the SK local 
client For instance, the reply includes the "ISK" signature 
which is embedded within the subject line. Other i^orma- 
tion includes the e-mail address of the recipient as well as ss 
the recipient's response (e.g., "accept") using delimited key 
words. Upon receiving the reply, the initiator can recognize 
that the response (e.g., an "accept" message or a "decline" 
message) corresponds to a particular invitation send out, 
thus facilitating decoding and processing of the message. In 60 
this manner, the response includes suflBcient scheduling 
information embedded within it to allow the initiator client 
to appropriately decode the re^onse, despite the fact that the 
responding recipient is a simple e-mail client without 
browser capability. 6S 

Regardless of which format the recipient employs, the 
group scheduling system of the present invention can pro- 



4 

cess the reply message automatically, including entering the 
appropriate information in the user's group scheduling cal- 
endar. In this maimer, the system of the present invention 
can support different levels of participation of various users 
(none of \^ch is required to have the system), throughout 
various stages of group scheduling. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A is a block diagram of a computer system in which 
the present invention may be embodied. 

FIG. IB is a block diagram of a software system of the 
present invention fisr controlling the operation of the system 

of no. lA. 

FIG. 2 is a bitmap saeenshot illustrating a user interface 
of a Personal Information Manager which embodies the 
present invention. 

FIGS. 3A-C * illustrate ' inteirclieiit' cbmmunicatioii' which" ' 
employs a message incorporating multi-format information 
embedded within. 

FIG. 4 is a bitmap screenshot illustrating a ''Deslq>ad" 
interface provided by the system. 

FIGS. 5A-I are bitmap screenshots illustrating a Sched- 
uling Wizard interface provided by the system for schedul- 
ing events. 

FIGS. 6A-<^ are bitmap screenshots illustrating a pre- 
ferred interface provided by the system for processing 
incoming event invitations. 

FIGS. 7A-C are bitmap screenshots illustrating a pre- 
ferred interface provided by the system for processing 
incoming replies. 

FIGS. 8A-G are bitmap screenshots illustrating a pre- 
ferred interface provided by the system for scheduling use of 
resources. 

FIG. 9 is a block diagram providing an overview of the 
internal architecture of a group scheduling system of the 
present invention. 

RG. 10 is a block diagram illustrating the general process 
of sending an event. 

FIG. 11 is a block diagram illustrating the general process 
of receiving messages. 

FIGS. 12A-C are bitmap screenshots illustrating receipt 
of an e-mail scheduling invitation by a recipient whose 
system represents a non-SK client without browser support. 

FIG. 13 is a screenshot illustrating receipt of an e-mail 
scheduling invitation by a recipient whose system represents 
a non-SK client with browser support. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

The following description will focus on the presenUy 
preferred embodiment of the present invention, which is 
operative in an end-user application nmning under the 
Microsoft® Windows environment. The present invention, 
however, is not limited to any particular one application or 
any particular environment. Instead, those skilled in the art 
will find that the system and methods of the present inven- 
tion may be advantageously applied to a variety of system 
and application software, including database management 
systems, wordprocessors, spreadsheets, and the like. 
Moreover, the present invention may be embodied on a 
variety of different platforms, including Macintosh, UNIX, 
NexlStep, and the like. Therefore, the description of the 
exemplary embodiments which follows is for purposes of 
illustration and not limitation. 
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System Hardware participate in group sdieduling. In particular, the present 

Hie iovention may be embodied on a computer system inventioo allows a user to ludertake group scheduling with 

such as the system 100 FIG. lA, which comprises a central other "remote" users located at different locations (including 

processor 101, a main memory 102, an input/output con- those with different time zones), regardless of what particu- 

troller 103, a keyboard 104, a pointing device 105 (e.g., j far platfoim or software applications each of the other users 

mouse, track ball, pen device, or the hke), a display or screen ^ employing. In contrast to prior art scheduling approaches 

device 106 and a mass storage 107 (e.g.. hard or fixal disk, ^hich required all useis to operate the same proprietary 

removable flo^y d^ optical disk, magneto-optical disk, ^ scheduling software, the present invention instead requires 

fladj memoiy). Althou^ f P'",*il*y? ^ oiUy one user of a workgroup to have the group scheduling 

system ctock is included wiA the system 100. m a conyea- ^^^^ ^ preSnt invention is fmbodied. Eve.^ 

tional manner. Processor 101 includes or is coupled to a j i . . , . , . . 

cache memory 109 for storing frequently accessed informa- ^^^V ^^^^ y**^'^^^ 

tion;memoryl09maybeanon-chipcacheorexterDalcache messages^ing any one of the wide variety of e-mail 

(as shown). One or more input/output device(s) 108, such as packages which are available. StiU further, the present 

a printing device or slide output device, are included in the invention includes facilities for accommodating even those 

system 100. as desired. As shown, the various components cannot receive c-maiL 

of the system 100 communicate through a system bus 110 or "E-mail" itself is a mcssaging-based approach which is 

similar architecture. In a preferred embodiment, the system employed by the present invention for communicating with 

100 includes an IBM PC-cornpatiblcTpe ' all users. The present invention implenientis a 'messaging 

available from a variety of vendors (inchiding IBM of subsystem or exchange which provide scheduling 

Armonk, N.Y). I/O device 108 may include a laser printer, 20 primitives — for example, "accept" and "decline" message 

such as an HP Laserjet printer, which is available from types — for supporting the basic functionality of group 

Hewlett-Packard of Palo Alto, Calif. scheduling. In typical operation, for instance, group sched- 

System Software uling begins with a user scheduling an event, that is, sending 

A. Overview to desired participants an initial meeting message or "invi- 

Illustrated in FIG. IB, a computer software system 120 is 25 tation" for scheduling the event. The event itself can be any 

provided for directing the operation of the computer system type of event, including those with a duration (e.g., meetings 

100. Software system 120, which is stored in system and appointments); as described below, "resources" (e.g., 

memory 102 and on storage (e.g., disk memory) 107, conference rooms, projectors, and the like) are also sched- 

includes a kernel or operating system (OS) 140 and a uled. The recipient user(s), once having received the 

windows shell 150. One or more application programs, such 30 message, can undertake one of several actions. The user can 

as client application software or '"programs" 145 may be accept or decline to participate, or the user can forward the 

'"loaded" (i.e., transferred from storage 107 into memory message to one or more other users. When declining a 

102) for execution by the system 100. proposed scheduling event, the user can propose another 

System 120 includes a user interface (UI) 160, preferably time for the event. When a user declines, he or she replies 

a Graphical User Interface (GUI), for receiving user com- 35 with a "decline" message; the message may indude one or 

mands and data. These inputs, in turn, may be acted upon by more alternative times proposed by the declining user. The 

the system 100 in accordance with instructions from oper- decline message is processed upon its return, whereupon the 

ating module 140, windows 150, and/or client application system automatically updates the scheduling calendar. An 

module(s) 145. The UI 160 also serves to display the results accepting user, on the other band, replies with an "accept" 

of operation from the OS 140, windows 150, and appUcation 40 message. Again, the group scheduling system processes the 

(s) 145, whereupon the user may supply additional inputs or message automatically, including entering the appropriate 

terminate the session. OS 140 and windows 145 can be information in the group scheduling calendar. In this 

provided by Microsoft® Windows 95, by Microsoft® Win- manner, the system of the present invention can support 

dows NT, or by Microsoft® Windows 3.x (operating in different levels of participation of various users (none of 

conjunction with MS-DOS); these are available from 45 which is required to have the system), throughout various 

Microsoft Corporation of Redmond, Wash. Although shown stages of group scheduling, 

conceptually as a separate module, the UI is typically B. Functional Overview 

provided by interaction of the application modules with the FIG. 2 is a block diagram illustrating a functional over- 
windows shell, both operating under OS 140. view of a group scheduling system 200 of the present 
One application software comprises a Personal Enforma- 50 invention, from the perspective of an end user. The system 
tion Management (PIM) System 125 which includes an includes a local client 210 comprising front-end software, 
Internet-based Group Scheduling Module 127 of the present inchiding a graphical user interface, for entering scheduling 
invention. The Intemet-based Group Scheduling Module information and generating group scheduling messages. The 
127 provides group scheduling among users connected to client 210 connects to transport mechanism or messaging 
the Internet or to other commercial service providers (e.g., 55 engine 220. This provides the mechanism whereby the client 
CompuServe). In an exemplary embodiment, PIM System 210 can send mcssagps to and receive messages from remote 
125 comprises Sidekick®, which is available from Starfish clients. 

Software, Inc. of Scotts Valley, Calif. A general description In a preferred embodiment, the messaging engine 220 

of the operation of Sidekick® can be found in its accom- supports Microsoft is Exchange or MAPI (Messaging Appli- 

panying user manual. Interface and methods provided by the 60 cation Programming Interface), AOL (America On Line), 

group scheduling module of the present invention, in the and POP 3 (Internet "Post OESce Protocol)" messaging 

exemplary embodiment of Sidekick®, will now be protocols. These widely-supported protocols can be 

described in further detail. employed for reaching remote clients having addresses (i.e., 

Peer-to-Peer Scheduling accounts) on the Internet, America On Line, Microsoft 

A. General 65 Network (MSN), as well as other systems which are acces- 

According to the present invention, if a user is able to sible through gateways (e.g., Compuserve, which has an 

receive and re^ond to e-mail, be or she should be able to Internet gateway). To further support each messaging or 
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mail system, tbe client 210 includes an address book module 
230, which comprises a separate address book for each 
messaging system. In an exemplary embodiment, for 
instance, the system provides support for AOL address book, 
Internet Q^etscape) address book, and MAPI-exchange 
address book. 

With the messaging engine connection, the client 210 is a 
''local" client which exchanges messages with various 
"remote" clients, such as client 240, client 250, and client 
260. As shown, there are different types of remote clients. 
One type of remote client is one which shares the same 
software group scheduling subsystem as the local client 210 
(i.e., it "understands" proprietary file formats of the local 
client 210). Such a client is shown at 240. Here, the local 
client 210 and the remote client 240 can of course commu- 
nicate directly using the proprietary format understood by 
both, in the same manner as presently done by present-day 
'pfoprietary^gixjup scheduling solutions." 

According to the present invention, however, a remote 
client may also comprise a generic e-mail client — that is, a 
client which does not share nor is even aware of the group 
scheduling software subsystem provided by the local client 
of the present invention. These "dumb** remote clients, such 
as represented by clients 250 and 260, simply have no 
knowledge or understanding of the scheduling format sup- 
ported by the local client 210. For clarity of the description 
which follows, the generic or non-proprietary clients are 
referred to as "non-SK" clients, for indicating that these 
clients do not have Sidekidc® — the proprietary software 
which implements automated group scheduling with both 
proprietary and non-proprietary clients. Those clients which 
do have Sidekick® are referred to a "SK" clients. 

With the ever-increasing use of the Internet and particular 
the rapid adoption of the World-wide Web ("Web") as a 
pervasive commumcation platform, an ever-increasing num- 
ber of Don-proprietary remote clients will have a standard 
browser, such as Netscape Navigator (available from 
Netscape of Mountain View, Calif.) or Microsoft Internet 
Explorer (available from Microsoft Corp. of Redmond, 
Wash.). As described in further detail below, the present 
invention may exploit this by using rich text messages, such 
as e-mail including one or more HTML (Hyper Text Markup 
Language) forms or "Web pages." Such a client, such as 
shown at 250 in FIG. 2, is identified as a remote non-SK 
client ''with browser." A simple e-mail client, on tbe other 
hand, is identified as a remote non-SK client "without 
browser." 

C. Interclient Communication 

The local SK client communicates with other clients by 
employing its messaging engine or transport layer to sends 
and receives electronic mail or messages. As illustrated in 
FIGS. 3A-C, each message itself is structured to facilitate an 
optimal communication protocol appropriate for the differ- 
ent types of clients (i.e., SK client, non-SK client with 
browser, or non-SK client without browser). This is 
achieved by incorporating into the message different formats 
of the scheduling message— one format for each particular 
chent type. 

To allow rapid identification of scheduling messages 
between SK clients themselves, an identifier or "signatxu^e*' 
is incorporated into the message by tagging the standard 
"subject line** in each e-mail message. In an exemplary 
embodiment, the initiator of a message (i.e., local SK client) 
includes the following unique identifier in the subject line of 
<ISK> or, alternatively, <SIS>. The interpretation of this 
depends on the actual type of client the recipient is. Remote 
recipient clients which do support the proprietary format of 
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the local client (i.e., recipient SK remote chents) can rec- 
ognize the identifier and readily identify the message as a 
scheduling message from another SK client. This allows all 
SK clients to easily identify scheduling messages among 

5 themselves, thus facilitating decoding and processing of 
messages. In the instance of one SK cHent communicating 
with another SK client, therefore, the recipient is a "smart" 
client with fiill knowledge and understanding of the type of 
message and bow to interpret it. 

10 One such SK-client-to-SK-clieot dialog is illustrated by 
interclient communication 300 in FIG. 3 A. Local SK client 
sends e-mail message 310. The message comprises the 
<ISK> (or other unique) identifier 311 together with a 
scheduling invitation in different formats. The different 

15 formats include, in order of increasing content richness, a 
simple text embedded scheduling invitation 313, an HTML 
(Hypertext Markup Language) form embedded scheduling 
invitation 315, and a proprietary^' binary'*' "MIME" 
(Multipurpose Internet Mail Extensions) scheduling invita- 

20 tion 317. 

Each format is designed to transfer the highest degree of 
information content which a particular target client type can 
handle. In FIG. 3A, for instance, remote client 320 recog- 
nizes from the identifier 311 that the message 310 is from 

25 another SK client — SK local client 301. Accordingly, the 
remote SK client 320 processes the binary "MIME" sched- 
uling invitation 317.This message is a SK-spccific message, 
allowing direct, proprietary communication between SK 
clients with the richest possible information content. 

30 Description of the MIME format is well documented in the 
trade literature; see e.g., Kientzle, T., MIME and Internet 
Mail, Dr. Dobb's Journal, September 1995, pp. 54-60 (with 
code listings pp. 104-110), the disclosure of which is hereby 
incorporated by reference. 

35 Since non-SK clients have no knowledge of the schedul- 
ing system, they simply ignore the identifier and the SK 
binary attachment. To allow the SK local client to commu- 
nicate with these non-SK recipient, the non-proprietary 
interclient communication formats 313, 315 are employed. 

40 As shown in FIG. 3B, for instance, remote non-SK client 
with browser 340 entploys the HTML form embedded 
scheduling invitation 315, which can be appropriately pro- 
cessed by its Web browser (e.g., Microsoft Explorer or 
Netscape Navigator); this represents the richest content that 

45 this client type can handle. 

The embedded HTML form (i.e., Wsb page) can easily be 
viewed by the Web browser as an input form having input 
fields corresponding to the information requested for sched- 
uling the event. For instance, the form may include text or 

50 input fields for subject, time, event, and the like. 
Additionally, the form can include screen buttons for allow- 
ing the recipient user to "accept** or "decline" the invitation. 
At the conclusion of completing the input form, the recipient 
user can select ''submit" for returning the input information 

55 back to the initiator. Here, the browser of the recipient 
generates a reply message, in a manner similar to that done 
today for on-line Internet registration. Upon receipt of the 
reply, the SK client 210 can identify, decode, and process the 
reply appropriately. Based on the action selected by the 

60 recipient (e.g., accept, decline, or die like), the SK client 210 
can update its scheduling information in an appropriate 
manner. 

In the event that the client is a non-SK client and does not 
have a browser, a simple messaging format is employed. As 
65 shown in FIG. 3C, remote non-SK client without browser 
360 processes the simple text embedded scheduling invita- 
tion 313, as this represents the richest content that it can 
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handle. Here, the recipient client receives a plain text e-mail 
message to which it can respond (e.g., "accept" or 
"decline"). In the client's response, the client includes the 
"body" of the initial invitation message. As is common in 
e-mail communication, the reply message can itself easily 5 
incorporate the contents of the original message. By simply 
including the initiator's original message when a non-SK 
cUent replies, the non-SK client is incorporating information 
which facilitates processing of the reply by the SK local 
client. For instance, the reply includes the "ISK" signature 
which is embedded within the subject line. Other informa- 
tion includes the e-mail address of the recipient as well as 
the recipient's response (e.g., "accept") using delimited key 
words. Upon receiving the reply, the initiator can recognize 
that the response (e.g., an "accept" message or a "decline" 
message) corresponds to a particular invitation send out, 
thus facilitating decoding and processing of the message. In 
this manner, the response includes sufficient scheduling 
information embedded within it to allow the initiator clienV ^ 
to appropriately decode the response, de^ite the fact that the 
responding recipient is a non-SK client without a 20 
browser — a simple, generic e-mail client 
D. Resource Scheduling 

When a meeting or an event is scheduled, often 
"resources" will be needed as well. For a board meeting, for 
instance, the board room needs to be available. The meeting 25 
might also require other resources, such as an overhead 
projector or a VCR. In accordance with the present 
invention, the scheduling system is extended to include 
these "resources." As with users, the resource scheduling is 
peer-to-peer — that is, it is shared among the users in a 30 
cooperative fashion. 

A resource itself "owns" an e-mail account — that is, it is 
able to send and receive scheduling messages. In this 
manner, scheduling of the resource can be completely auto- 
mated. Here, the resource is controlled by an SK client, 35 
which manages the calendar for the resource. When a 
request is received to schedule the resource, the SK client 
can check its calendar and respond whether the resource is 
available, all in an automated fashion. For the example of a 
board room meeting, the board room resource is, in effect, 40 
"invited" to the meeting. Through the SK client which is 
controlling the scheduling calendar for the board room, the 
board room can "reply." In a preferred embodiment, ao 
immovable resource (e.g., "room" resource) cannot be 
scheduled to attend two meetings at the same time. A person, 45 
on the other hand, can t>e scheduled for two meetings at the 
same time; in that instance, the person decides which 
meeting to attend (i.c., which one is more important), or 
decides to attend certain portions of each meeting. 
Preferred Interface and User Operation 50 

A. General Interface 

As shown in FIG. 4, the system provides a "Deskpad" 
interface 400 — that is, a personal informatioQ management 
interface which includes an electronic appointment calendar. 
The interface 400 includes a menu bar 410, for invoking ss 
menu items or commands. The interface itself is comprised 
of particular subrcgions. A first subregion 420 displays the 
current time and date. Below this region arc a To Do region 
430 and a Call region 440. The former lists To Do items 
which the user has included. The latter is a log of calls which 60 
the user wishes to track. Actual schedule events or appoint- 
ments are displayed in the interface at region 450. By 
default, appointments are displayed in one's own local time. 
The interface also includes a quick lookup or viewport 460, 
for working with another view of the interface (e.g., "Card- 6S 
file" view). Finally, the interface includes. Deskpad icons 
470, for quickly switching to other modules of the system. 
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The interface 400 provides different "views": Calendar 
view, Cardfile view. Write view, Expense view, and Activi- 
ties view. The Cardfile view can be used as an address book 
in which the user stores names, addresses, e-mail addresses, 
phone numbers, and other information (e.g., record 
collection). The Cardfile works with the Calendar's Internet 
group scheduling to address event invitations, and also can 
kx>k up phone numbers of incoming calls using Caller ID. 
The user can use the Cardfile with the Phone Dialer to dial 
calls, or merge card information into a letter using Quick 
Letter. The Write view provides a place to create and format 
documents, organized in folders and binders. The Expense 
view lets the user enter information from expense receipts, 
and organize expenses in folders. The user's expenses are 
printed in a finished expense report. The Activities view 
presents information about all the user's group scheduling 
events plus other Calendar activities: one's calls. To Do 
items, and individual appointments for the period selected. 
The Activities view is employed to reply to group event 
invitations and view replies to group events the user has 
originated. 

Of particular interest to the present invention is the 
Calendar view which, as shown in FIG. 4, displays the user's 
Calendar. Here, the user creates appointments and uses 
Internet-based messaging (or other electronic messaging 
service) to automatically handle invitations and replies for 
scheduling group events. The appointments adjust to the 
user's own local time zone, if the user travels with the 
computer when he or she switches to the new local time in 
an "EarthUme" module of the system. The EarthUme 
module tells the user the current time in eight locations 
around the globe, and provides other information such as 
time difference start and end of daylight saving time, and 
other facts about each city, for over 540 cities. Further 
description of the EarthTime module is provided in 
commonly-owned application Ser. No, 08/609,983, filed 
Feb. 29, 1996, which is hereby incorporated by reference. 
When desired, the user can print the Calendar in a variety 
formats, including page sizes suited to the most popular day 
planners, such as Keith Clark, DayRunner, Day-Timers, and 
Franklin Planner. 

B. Peer-to-Peer Scheduling Interface 

1. Overview 

The Group Scheduling module 127 uses electronic mes- 
saging to conmiunicate with others to schedule events and 
book resources. Because it supports numerous e-mail 
platforms, including the Internet, the module can provide 
group scheduling with users anywhere in the world. The 
system automatically invites the participants to an event the 
user schedules, and collects their replies for accepting or 
declining the invitation or for requesting that the user 
reschedule it. The event is automatically placed in the 
Calendar in the Calendar view, as well as the recipients' 
calendars if they accept. Additionally, the user can also 
automatically reserve resources for the event, such as con- 
ference facilities, projectors, and others. Most of the group 
scheduling occurs in the Activities View, where the user can 
see all group events in list form. Events the user schedules, 
or that the user accepts an invitation to, are also posted 
automatically in the user's Calendar. 

To schedule an event, the user enters the details of the 
meeting and the list of people he or she wants to invite. The 
system then automatically notifies the recipients and collects 
their responses for the user. In addition to electronic 
messaging, the user can use fax or telephone for group 
scheduling, for people without e-mail accounts. If the user 
specifies a fax number for notification, the event invitation 
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is automatically sent using built-in fax software (e.g., Web) to add an Internet address as part of the message 

Microsoft Fax) and the user's fax modem. Selecting phone information. Users receiving the URL can click on it to 

notification, on the other hand, puts a reminder in the user's launch their Web browser and jump to the URL site. At 543, 

Calls list. the user can select a file to send as an attachment to the 

2. Scheduling Wizard s meeting invitation. The user proceeds to the next pane by 

The system provides a convenient ''Scheduling Wizard" selecting Next button 544. The next pane or page is the 

to assist the user in the process of entering event informa- "Resources" page, illustrated in FIG. 5G, where the user 

tion. It helps the user enter all the information about the selects one or more resources from a list 551 of available 

event, and identify the participants he or she wants to invite. resources. The user clicks the selection buttons 553 to add or 

The user also can create a group event using a "Schedule an lo remove items from the Event Resources list 552. By clicking 

Event" dialog box. The user can include a message with the Next button 554, the user proceeds to the next page, 

invitation, and the replies can include a message and a report The next page is the "Event options** page, illustrated in 

on free time if a recipient cannot attend at the scheduled FIG. 5H. At 561, the user can select a check box to send a 

time. If the user needs to notify some people by fax or phone, reminder as well as set an amount of advance notice. By 

he or she can enter their reply status manually. 15 checking "Page Me" or "Alert Me" and setting a time, the 

The easiest way to enter group event infonnation is using user can instruct the system to remind the user by page or 

the Sdicduling Wizard. To schedule an event in the Activi- alarm. The user selects the RSVP radio button, in Event 

ties or Calendar view, the user selects lnternet|Scheduling ' Options box*562, to request a reply, "or selects the FYI radio " 

Wizard from the main menu, as shown at 501 in FIG. 5A button to send an announcement only. By selecting RSVP 

This action launches Scheduling Wizard 510, as shown in 20 (i.e., "please respond"), recipients can send back a reply 

FIG. 5B. The wizard consists of a series of pages that prompt whereupon the system automatically collects the informa- 

the user to enter the information for the event, such as tion for the user. If the user chooses FYI (i.e., "For Your 

participants, resources, agenda or notes, and options. The Information"), on the other hand, he or she is sending an 

user enters the information in each page, and clicks "Next" announcement of the event, without requesting replies. This 

to proceed to the next page. The user can go back at any time 25 option is used, for example, for events such as a company 

to earlier pages if he or she needs to change something. meeting that will occur regardless of individual schedules. 

When the user has finished, they system displays an Event Additionally, in Event Options box 562, the user can instruct 

Summary. Here, the user can review his or her choices, and the system to enter this Event in the user's Contact Log. 

make changes, if necessary, by going back to previous Upon checking the box, the event is entered in the Contact 

pages. When the user is ready to schedule the event, the 30 Log for each participant in the invitation list. Finally, the 

Wizard adds it to the user's queue of outgoing messages, and user can specify a type for the event: Public, Personsd, or 

put it on the user's calendar. To use Internet scheduling, the Confidential. f 

user creates a cardfile that contains properly identified Upon Electing Next button 563, the i^er instructs the 

e-mail addresses for the people the user will be inviting, system to proceed to the "Schedule the Event" page, illus- 

Altematively, the user can use an existing Netscape Address 35 trated in FIG. 51. Here, the user can review the selections, at 

Book or Microsoft Exchange Cardfile for addressing. 571, and go back to any previous page, if needed. Once 

The wizard is used from start to finish as follows. First, satisfied with the selections, the user selects "Finish" button 

the user enters an event type. As illusfrated in FIG. 5C, the 572 to schedule the event Alternatively, the user can cancel 

user clicks an event category at 511 and selects a particular the input altogether by selecting "CanceL" 

subject — that is, an event type to schedule. When the user 40 The user can also include people who do not have e-mail 

has completed each Wizard panel, the user clicks "Next" in the list of event invitees. Here, two options exist for 

button 512 to continue. Alternatively, the user can click addressing invitations: fax or telephone. If an invitation is 

"Back" to return to an earlier panel. Next, in FIG. 5D, the directed to someone at their fax address, the system launches 

user invokes the "Date and Time" page. Here, the user the fax software (e.g., Microsoft Fax) and faxes the invita- 

reviews the subject presently entered, at 521, and then enters 45 tion automatically. If the user selects someone's telephone 

a date and time for the event, at 522. The user can select the number as their address, a reminder is added to the user's 

date by typing or by using the arrows. A calendar can be Calls list in the calendar to call that person. When the user 

opened at this point (e.g., by selecting the large arrow). The hears from these people, he or she can enter their meeting 

user also enters the start and end times. Next, the user selects reply by entering the appropriate status: Accept, Decline, 

or types the city where the event is to occur, at 523. The time 50 Reschedule Request, or Delegate, 

zone fills in automatically. After typing or selecting a place, 3. Incoming Event Invitations 

the user advances the wizard to the next pane by selecting When the user receives an invitation to an event, it 

Next button 524. appears in bold type in the Activities view 600, which is 

TTie next pane is a "Participants" page, illustrated in FIG. illustrated in FIG- 6A. An icon appears in the News column 

5E, which allows the user to select participants. At 531, the 55 623 to indicate a new event. The user will see the incoming 

user chooses an Address Book or a mailing list; clicking event invitation in his or her e-mail in-box, marked with the 

"More" opens a different Address book. Now, the user clicks signature (e.g., <ISK> for Internet Sidekick) in the subject, 

the folder next lo each name, and clicks the notification In typical operation, the user disregards this message in his 

method (i.e., e-mail, fax, or the like) for that participant. The or her e-mail in-box, as the system will automatically find 

user adds desired selections to the Participants list 533 or CC 60 and handle it for the user. Users who have other systems, on 

list 534, using selection buttons 535. Thereafter, the user the other hand, can open the message like any other e-mail; 

moves to the next pane by selecting Next button 536. On the it contains instructions on how to reply so the original 

"Message" page, shown in FIG. 5F, the user types the sender's system (i.e., SK client) will be able to record the 

agenda or notes, at 541 . From buttons 542, the user can click reply. 

a "Message" button to select a file containing a message. 65 To get to the Activities view, the user click the Activities 

Alternatively, the user clicks "Attach URL" (Uniform icon (or selects the corresponding menu command). After 

Resource Locator, the address of a site on the World Wide the user has clicked Group Events tab 611, status infotma- 
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tion is displayed for group events in the three left-hand ignore the messages, since the system will read aod process 

columns, lype column 621 displays an icon for the event these automatically. 

type: (b 1) New event the user initiated; (2) New incoming Non-SK client users can open the invitation like any other 

event, and (3) Incoming event the user has opened. News e-mail item and read the contents, which are stored in 

column 623 displays an icon for all new items: (1) New 5 formatted text. The body of the message includes instruc- 

event information; (2) Reply has arrived; and (3) Event has tions that explain briefly how a non-SK client user can reply, 

been canceled. Out-box column 625 indicates messages that To reply to an invitation using conventional e-mail software, 

are queued to be sent during the user's next e-mail flash the non-SK client user proceeds as follows. The user opens 

session; it displays an icon indicating Messaging waiting to the invitation in his or her e-mail in-box, like any other 

be sent. The user can select an Internet (Send/Receive Now lo message. Using the user's own e-mail software (from any 

command to send pending messages immediately. By cUck- vendor), the user "replies" to the message, and includes the 

ing on a Detail item 627, the user can display further body of the original message in the reply (i.e., does not 

information in Details and Information pane 629. modify the contents). The subject field of the reply will 

To reply to an event invitation, the user reviews the event already include <ISK> indicating that the reply is an Internet 

specifics in the Details and Information panes. Then, the user 15 Sidekick scheduling message. In the body of the message, 

clicks a choice to reply from the buttons at the bottom of the the user finds a section labeled ''Your Reply." Here, the user 

window (e.g., "Accept," "Decline," "Reschedule," or the simply types an "X" in the brackets next to Accept or 

' "like). Alternatively, the user' can rightKihck an event i^^ " Decline, so that the reply*^ reads "[X] Accept" of "[X] 

top pane, and choose from a Shortcut menu. In a preferred Decline"; the replying user can also type a brief message in 

embodiment, the user's reply is sent only to the originator, 20 the space between the markers reading <BEGIN REPLY 

not to others invited to the event. MESSAGE> and <END REPLY MESSAGE>. Now the user 

Accept button 631 lets the user enter a short reply simply sends the reply. The originator's SK client will be 

message (via Reply dialog 635 in FIG. 6B), and then sends able to process the reply automatically and mark the appiu- 

the acceptance to the initiator confirming that the user will priate status for that recipient, 

attend. The event is automatically added to the user's 25 5. Incoming Replies 

calendar. Decline button 633, on the other hand, sends a The originator's SK client automatically collects reply 

reply message to the initiator that the user will not be able messages from people whidi were invited to an event and 

to attend. The event is not added to the user's calendar. With displays the replies in the Activities view. As rephes arrive, 

the user's reply, the user can include a Free Time report the user is notified by an icon in the News column (623 in 

showing the user's booked and unbooked time for the next 30 FIG. 6 A). The user can click the participants' names in the 

30 days (or other user-specified interval), for assisting the Activities view, and read their reply status, as well as any 

meeting originator in rescheduling. Included in the Free reply message they may have sent, in the Details and 

Time report is an indication of all the times for the next 30 Information dialog 700, shown in FIG. 7A. By clicking the 

days when the user has a scheduled event, and all other (free) + sign by the participants in Details pane 701, the user can 

times. In a preferred embodiment, no information about 35 expand die list. By clicking a participant, the user can view 

specific events on the user's calerriar is sent, beyond the the reply message in Information pane 703 and expand the 

indication that the time is booked. The user checks box 637 Details and Information panes to full-screen, as desired, 

to include the report. The originator user can reschedule an event which he or 

In addition to accepting or declining, the recipient user she originated by selecting the event and clicking Resched- 

can request rescheduling of the event. Here, the user selects 40 ule button 711. This action di^lays a **Schedule an Event" 

Reschedule Request button, such as button 635 in FIG. 6A. dialog box v^ere the user enters the new date and time 

In response, the system displays Reschedule Request dialog information, and any other changes. The user is asked if he 

640, as shown in FIG. 6C. This option sends a reply orshe wants to notify all participants and resource managers 

requesting that the event be moved to another time or date. about the change. If the user selects ""Yes," notification is 

In the dialog, the user can enter one or more alternate times 4S automatically sent. 

for the event, as well as include a short message. As with the In a similar manner, the user can cancel an event he or she 
decline response, the user has the option of including a Free originated by selecting the event and clicking Cancel Event 
Time report to assist the meeting originator in rescheduling. button 713. The user will be asked to confirm that he or she 
The Minutes button 634 is used to send notes or minutes to wants to cancel the event and notify all participants; select- 
all participants. This launches a ''Compose the Minutes" so ing **Yes" cancels the event. Alternatively, the user can 
window where the user can write a message or attach a file delete group scheduling events in the Activities view to 
(by clicking a Browse button); the minutes are automatically clean up his or her events list. This is done by selecting one 
distributed lo the participants. or more events and pressing the Del key, or by right-clicking 

Besides accepting and declining, the user can "delegate" an event and choosing Delete from the menu. In contrast to 

the event by choosing the option from the menu. The option ss canceling, the action of deleting group events in the Activi- 

opens a Delegate To dialog box (not shown), where the user tics view does not remove them from the user's calendar, 

can specify a person to forward the invitation to. Here, the and does not notify meeting participants. It is used only to 

meeting originator is notified that the user has delegated the clean up the Activities list display. To delete a group event 

event to someone else. the user has originated and notify participants, the user 

4. Replying to Incoming Event Invitations for Non-SK 60 cHcks the Cancel Event button 713 or deletes the event in his 

Clients or Calendar. 

Users who are non-SK client users (i.e., do not have Also in the Details and Information dialog 700, the user 

Internet Sidekick installed) can still reply to incoming can elect to send a reminder to all event participants in 

invitations in a way that is automatically recorded by the advance of a meeting. This is done by selecting the event and 

event originator's. All event invitations, whether the recipi- 65 cHcking Send Reminder button 715. Alternatively, the user 

ent is a non-SK client user or an SK client user, appear in the can arrange for the reminder when the user initially creates 

user's e-mail in-box. Users who are SK client users can the event. 



01/08/2004, EAST Version: 1.4.1 



6,016,478 



15 



16 



10 



If the recipient attaches a Free Time report (e.g., when 
declining or requesting rescheduling of the invitation), his or 
her Free Time report appears with the reply message, as 
indicated by Free Time button 721 in FIG. 7B. The Free 
Time report shows when the recipient has events booked and 
what times are free, during the next 30 days, as described 
above. It can be viewed by clicking on the Free Time button 
721, whereupon the system displays Free Time report 723, 
for the reply. The report is useful in determining an alternate 
meeting time, especially when scheduling several people. 

6. Entering Replies Manually 

For people who are invited by fax or phone, the user can 
enter the reply status manually. To enter reply information 
manually, the user selects the event from the list (in the 
Activities view). Next, the user selects the participant's 
name to bring up that individuals details io the Details pane. 
Now, the user can enter the status by right-clicking on the 
■participant's name, to- bring up pop-up menu- 740, shown in 
FIG, 7C. Here, the user can enter: "Accepted," "Declined," 
"Reschedule Requested," "Delegated," or "No Reply Yet." 

C. Resource Scheduling Interface 

1. General 

Resources are facilities such as conference rooms or 
equipment that the user wants to be able to schedule. The 
system of the present invention groups resources in one of 25 
the following resource types: 

1. Facilities — a resource such as a conference room or 
other immovable location. Facilities can have a Maxi- 
mum Occupancy setting. The system maintains a cal- 
endar for facilities and confirms or denies bookings 30 
automatically based on the calendar. 

2. Equipment — a movable resource such as a projector or 
vehicle. The system maintains a calendar for equipment 
and confirms or denies bookingis automatically based 
on the calendar. 

3. Other — private resource which an individual user 
wants to keep track of, such as booking a conference 
call operator, or ordering catering for a meeting. There 
is no calendar for this category, and entries are recorded 
under the user's To Do items. 

Since resources typically do not have their own e-mail 
accounts, each resource has a "manager," whose e-mail is 
used to handle the calendar and messaging for reserving the 
resource. Typically, the manager is the person who creates 
the resource in the system of the present invention. Using the 
e-mail account of the manager, the system handles resource 
scheduling automatically in the badqground; the manager is 
not involved in these transactions. Alternatively, a resource 
can be given a dedicated e-mail account, whereupon the 
system uses it for automated scheduling of that resource. 
Once a resource has been added to the e-mail system (either 
to its own e-mail account or that of another's), it is distrib* 
uted to others to make it available to them for booking. 

2. Reserving a Resource 

The user can request a resource reservation as part of 55 
creating a group event. However, the user may want to do it 
separately, in advance, so he or she can be sure the resource 
is available before sending meeting invitations. To reserve a 
resource without scheduling the event, the user employs a 
Reservation Wizard of the present invention, which will now 
be illustrated. 

To reserve a resource such as a conference room or 
projector using the wizard, the user selects 
Internet|Reservation Wizard from the system menu. This 
displays the first Resource Reservation Wizard dialog 800, 
Step 1 (Facilities and Equipment), as shown in FIG. 8 A. The 
dialog lists resources which have already been distributed to 



the user (and others), or have been created by the user. Here, 
the user chooses the facilities and equipment he or she wants 
to reserve by selecting each item. The user can reserve 
multiple resources by clicking each one. By clicking Details 
button 801, the user can see detailed information about a 
selected resource. When finished selecting resource, the user 
clicks "Next" button 803, to proceed to the next wizard 
dialog. 

The second Resource Reservation Mzard dialog 810, 
Step 2, is illustrated in FIG. 8B. In Step 2 (E>urpose and 
Time), the user enters the time and purpose for reserving the 
resource. When finished with Step 2, the user clicks Finish 
button 815. Based on the user's inputs, the Reservation 
Wizard sends out a request to book the resource for the time 
specified. The request is sent to the computer of the 
resource's manager (via e-mail account) for processing by 
the SK client. A reply message is sent back to the requestor's 
computer automatically, without requiring any action by the 
resource's manager.' If the resource is Available, the reply* 
message confirms the reservation. If the resource is 
20 unavailable, a message listing available times is sent instead. 
In this case, the user can reschedule by again choosing 
lnternet|Resources|Reservation Wizard and changing the 
times as needed before re-sending the request. 

3. Adding and Distributing Resources 
25 The person who is going to manage the resource is usually 

the one who adds it using an Add command. This is selected 
from the system menu by choosing Intemet|Rcsources|Add. 
In response, the system displays Add Resources dialog 820, 
illustrated in FIG. 8C. Here, the user enters the name of the 
resource together with the e-mail type and account infor- 
mation; the latter two are aiUomatically picked up from 
•existing user preferences. The phone number field and other 
Ijfields are included for convenience* in case others have 
^^questions about resource reservations. The prooes$ is com- 
35 pleted by selecting Add button 821. 

After a resource has been added, it can be distributed. 
Distributing" a resource is the process of making it avail- 
-Jable to others for reserving. The manager distributes it to the 
users who will be reserving it. Anyone to whom the resource 
is distributed can distribute it to additional users: To distrib- 
ute a resource to other users, the user selects a Distribute 
command from the menu. In response, the system displays 
Distribute Resources dialog 830, ilhistrated in FIG. 8D. At 
831, the user clicks one or more resources that be or she 
manages and wants to distribute. At 833, the user selects 
users to distribute resources to. 

4. Managing Resources 

The system of the present invention provides tools that let 
the user print resource schedules and modify or delete 
resources from his or ber system. The user can view and 
print the schedule of any resource that he or she manages. To 
view a resource's schedule, the user chooses 
Interne t|Resources|View. In response, the system displays 
Viewing Resources dialog 840, illustrated in FIG. 8E. From 
pulldown list 841, the user can select a particular resource to 
view and then dick to print the schedule for the resource in 
weekly or monthly view. 

To modify a resource (i.e., change the properties of a 
resource), the user chooses Intemet|Resources| Modify from 
the menu. This opens a Modify Resource dialog box, which 
is similar to the Add Resource dialog box except that the 
user cannot modify the resource name. To remove a 
resource, the user chooses' Intemet|Resources|Remove, 
selects a resource from a displayed list, and clicks 
"Remove." 

If the user modifies or removes a resource that he or she 
does not manage, the user is affecting the local resource file 
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only. The user might want to delete a resource that he or she 
never uses, or might want to change a resource's descriptioo 
or owner information as displayed on his or her system. 
Since these changes affect the user's local system only, they 
do not affect others who also reserve that resource. If the 
user is the owner of the resource, deleting it has wider 
impact. By deleting that resource, the user removes the 
resource's calendar, making it impossible for anyone to 
schedule that resource. If the user simply wants to stop 
managing the resource, he or she should "transfer" the 
resource. 

Transferring a resoiircc is the act of assigning a resource 
the user owns to another manager. This is done by choosing 
Interne t|Resources|Transfer from the menu. In response, the 
system displays a Transfer Resources dialog 850, illustrated 
in FIG. 8F. Here, the user selects the resource from resource 
list 851 and then clicks Transfer button 853. The system now 
- displays. a second Transfer.Resources dialog 860, shown in 
FIG. 8G, for entering information about the new resource 
manager. Transfer is completed by clicking Transfer button 
861. 

Internal Operation 

A. Overview of Architecnire and Basic Operation 

FIG. 9 is a block diagram providing an overview of the 
internal architecture of a group scheduling system 900 
constructed in accordance with the present invention. The 
group scheduling system 900 includes a main module 910 
comprising a user interface 911, a composer 912, a parser/ 
interpreter 913, an e-mail send/receive interface 914, a 
calender interface 915, and an Activities view module 916. 
The user interface module 911 supports entering, editing, 
and deleting of group scheduling information. The composer 
912 is employed for actually composing a group scheduling 
message. Hie message itself, when it is received by another 
SK client, is parsed and interpreted by the parser/interpreter 
913. The e-mail module 914 supports the sending and 
receiving of e-mail messages and documents, using com- 
mercial available e-mail providers. The calendar interface 
915 allows the main module or engine 910 to communicate 
with a separate calendar module 920. The Activities view 
module 916 supports the previously-demonstrated user ses- 
sions in Activities View mode of operation. 

General operation of the system can be divided into two 
tasks: sending an event and receiving an event message. The 
general process of sending an event is illustrated by Send 
Event Method lOOO, shown in FIG. 10. The process begins 
with the user entering event information in the user 
interface, as indicated by step 1001. The composer module, 
acting on the user information, proceeds to compose the 
event scheduling message, at step 1002. At the point of 
composing a message, the system provides a variety of 
different message types, each corresponding to a particular 
state a meeting is at. Once a message has been composed, it 
can be inserted into the calendar, as shown by step 1003. 
Thereafter, the system schedules the message to be sent via 
the e-mail tran^rt layer, as indicated by "e-mail delivery" 
step 1004. Once the message has been sent, the Send Event 
Method 1000 is done. 

The general process of receiving messages is illustrated 
by Receive Event Method 1100, illustrated in FIG. 11. At the 
outset, the process spawns a separate thread to receive an 
event message, at step 1101. As shown by step 1102, at a 
predetermined interval a "flash" session is initiated. During 
the flash session, the system polls the user's in-box, for 
identifying incoming scheduling messages (i.e., those hav- 
ing the signature <ISIC>). 

The incoming scbediiling messages are parsed by the 
parser (913), as shown at step 1103. The parser extracts 
scheduling information from the messages, storing it in an 
internal representation suitable for use by other modules of 



the system. The parser identifies, for instance, the <ISK> 
identifier, date and time information, message-type infor- 
mation (e.g.. Schedule, Reschedule, Cancel, and so forth), 
and the tike. The parsed information is, in mm, passed to a 
general message handler at step 1104. In response, the 
message handler triggers one of several actions, as indicated 
by step 1105, by invoking more-specific handlers — ones 
which perform the requested action. Actions include, for 
example. Schedule New 1105a, Reschedule 1105 B, Cancel 
1105c, Minutes of Meeting 1105rf, Resource Reservation 
1105^, and the like. At step 1106, the parsed information is 
stored in the group scheduling database (950). From here, 
the information will also be employed, at step 1107, to 
update the calendar and/or a resource manager, as needed. 
Once updating is complete, the method is done. 
15 B. Core Data Structures 

1. Group Item and Group Attachment 
Before describing the internal methods of operation in 
further detail, "it is first helpful 'tb' exffiine iiiteiT^ 
strucmres which support operation of those methods. A 
20 group scheduling item is represented internally in the system 
by a "Group Item" data structure, GROUP_JTEM. In an 
exemplary embodiment, this structure maybe constructed as 
follows (using the C/C++ programming language, for 
instance). 
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typedef struct 
{ 

DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
HANDLE 



1 
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dwEventlDl; 
dwEvcntlEKZ; 
dwHiomDateUme; 
dwToDateHnie; 
dwOldFromDtatcTime; 
dwOlcfroDaleTimc; 

dwSendReceiv^ 
hText; - ' 

HOLOBAL hRectpient; 
DWORD IfData; 
LPGROUP_ArTACHMENT IpAttach; 
// READ_IN_MAIN; READ_IN_^rtTrACH; FTMPHLE; 
DWORD wFlags; 

wFlags2; 
nlbxts; 
oRedpieats; 
oPageHour; 
oPageMin; 
bl^pcs; 
bTlmeZooe; 
bLead; 
bLeadUnit; 

total 64 bytes 
LPGROUP_[TEM; 



DWORD 

short 

short 

short 

short 

BYTE 

BYTE 

BYTE 

BYTE 
} GROUP^TTEM; // 
typcdcf OROUP_ITEM 



As shown, the GROUP_ITEM data struaure includes 
two event IDs: dwEvcntlDl and dwEventID2. Together, 
these comprise a 64-bit (i.e., two double words) identifier for 
each scheduling group item. This ID is employed among the 
various clients for uniquely identifying a particular group 
scheduling item. Next, the data structure stores "from" and 
''to" date and time information in dwFromDateTime and 
dwToDateTime data members, respectively. Additionally, 
the particular item might comprise a "reschedule" item and, 
therefore, need to store the original ("old") date and time. 
This information is stored in dwOldFromDateTime and 
dwOldToDateTime data members. The dwSendRecieve data 
member also stores date and time information; it is 
employed as a time stamp indicating when a group item is 
sent or received. 

Following the date/time data members are two handles: 
hText and hRecipient. The hText data member is a handle to 
a text buffer for the subject line (e.g., 256-character string). 
The hRecipient data member, on the other hand, is a handle 
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pointing to a recipient block — a memory block storing N 
number of recipients. The IfData member serves as a pointer 
to the detailed data — that is, the data which follows the 
subject line. 

This is followed by another pointer, IpAttach, which 
points to a group attachment data structure. The group 
attachment information is, therefore, nested within (via a 
pointer) each GROUP_ITEM record. In an exemplary 
embodiment, a "Group Attachment" data structure, 
GROUP_^ArTACHMENT, may be constructed as follows. 



#defuie ARRAY_LEN 

typedef strua 



63 



{ 



WORD 



wFlags; 



// IS_MEEnNGNOTE_nLE 
// if on then meeting note saved in file 
// REMINDER_SENT 

' nAttachSizc; - - 

wRcscrvcd; 
IpAttachFile; 

hReg^ding; 
nRcgarding?; 
IpMeetingNote; 
oMeetingNotes; 
5zLocation[ARRAY_a£N+l]; 
s2aty[ARRAY_LEN+l]; 
} GROUP_jaTACHMENT; // 156 bytes; 
typedef OROUP_AnACHMENr • LPGROUP__AnACHMENr» 



-short • - 
DWORD 
LPSTR 
HGLOBAL 
UtNT 
LPSTR 
UtNT 
char 
char 
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As shown, the data structure includes as its first member 
nAttachSize, an integer storing a size for the attached file. 
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This is followed by wReserve which comprises a double 
word (DWORD) currently not used. The IpAttachFile data 
member stores a pointer to a text string comprising the name 
of the attach file (which itself is stored on disk). 

The next data member, hRegarding, is a handle pointing 
to a "regarding" structure which comprises the message 
body — that is, what the event is in "regards" to. This is 
followed by an integer data member, nRegardings, which 
stores a size for the regarding block which is being pointed 
to by the hRegarding handle. The IpMeetingNote data 
member is a pointer to a text block comprising a user- 
supplied meeting note text string. The size of this pointed4o 
data structure is stored by nMeetingNotes. Finally, the 
location (e.g., particular conference room) and city where 
the meeting or event is to occur are'stdfed by szCbcation and ' 
szCity character strings, respectively. 

Returning to description of GROUP_ITEM data 
member, the next data member in the GROUP_JTEM data 
stmcture is a double word, wFlags, storing a set of flags. The 
flags indicate various information for the group item and 
group appointment (described below), including, for 
example, whether the event is Canceled, Rescheduled, or 
Deleted. In an exemplary embodiment, the following flags 
are defined. 



// flags for GROUP_APPOINrMEr«- and 

#define READ__IN_MAIN 

#dcfine READ_IN_ArTACH 
// #define FTMPFILE 

#define HAS_MEETtNG_NOrE 

#define EVENr_CANCELED 

#define EVEm'_RESCHEDULED 
// #defiiie EVENT_DELETED 

#define SCHEDULED^EVENT 

#dcfinc SEND_jlEMINDER 

#defme REMINDER_JSENT 

#define SEND_X.ATER 

#dcfmc NO_REPLY_NEEDED 

^define RECEIVED_EVENT 

#define EVENT_^CCEPm> 

#dcfmc EVENT_JOECLINED 

#deflne UNREAD_EVENr 

Mefine EVEKr_J^RWARDED 

#deiine SBr_j\LARM 
oaly 

tfdefine SnAMP_TO_CARD 
only 

Mefine ArrACI131Y_CAl£NDAR 
only 

#dcfinc RESOURCE^EVENT 

#dcflne FREETIME^EVENT 

#define PERSONAU_EVEOT 

#dcfinc CONHDENTIAUVENT 

#deflne PAGE_ME 

#dcfine UNCONFlRMED_EVENT 

ttdcfinc COMPLETED_EVENT 

#dcflne UNBOOKED__EVEOT 

#define EVENT_RESCHEDULE_REQUIRED 
// Mefme 0x40000000 

#deflne EVEOT^KECEIVEJORWARD 



UP_JTEM.>«i'lags 
QxOOOOOOOl //both 

0x00000002 //both 
0x0004 //both 
0x00000008 // both 
0x00000010 //both 

0x00000020 // both dwOldDatcUme good 

0x00000040 //both 
0x00000080 // scheduler side 
0x00000100 // scheduler side 
0x00000200 // scheduler side 
0x00000400 // schedxilcr side 
QxOOOOOSOO //schedidetside 
QxOOOOlOOO // receiver side 
0x00002000 // receiver side 
0x00004000 // receiver side 
0x00008000 // receiver side 
QxOOOlOOOO // receiver side 
0x00020000 // for OROUP_APPOINTMENT 

0x00040000 // for GROUP__APPOIOTMENT 

QxOOOfiOOOO // fosr GROUP_APPOINTMENT 

0x00100000 
0x00200000 
0x00800000 
0x01000000 
0x02000000 
0x04000000 
0x08000000 
0x10000000 

0x20000000 // receiver side 
0x80000000 // the second recipient 



The flags can be combined (i.e., bitwise "or" operation), for 
65 storing in a single double word. 

The GROUP_rrEM data strucmre stores a second set of 
flags in another double word data member, wFlags2. In an 
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exemplary embodimeDt, these additional flags are defined as 
follows. 



// edditional flag? 

#dcftnc EVENT_OUEUE_rrEM 0x00000001 

#dcftnc EVENT_NEW_JTEM 0x00000002 

^define EVENT_RECE[VE_RESCHEDULE 0x00000004 

Weanc EVENT_RECE[VE_CANCEL 0x00000008 

#define EVENT_RECErVE_REMINDER 0x00000010 // receiver side 

#definc UNREAD_MEE11NG_J^0TE 0x00000020 

#definc EVENT_RECEIVE_JIEPLY 0x00000040 



Following the flags, the nText data member stores a byte 
count corresponding to the size of the block pointed to by the 15 
hTexl handle (described above). The nRecipients data mem- 
ber stores a count for the number of recipients; in an 
exemplary embodiment, up to 32,000 recipients are sup- 
ported. The next two data members, nPagcHour and 
nPageMin, specify a time to page the user; this corresponds 20 
to the "page me" reminder feature previously described (for 
the Scheduling Wizard, io FIG. 5H). In an exemplary 
embodiment, the page time is specified as a time interval in 
advance of the event or meeting, such as "^three hours 
before" the meeting. This serves to remind the user so that 
he or she will not forget a meeting which he or she 
scheduled. 

The next data member, biypes, stores a value describing 
the item. In an exemplary embodiment, the following types 
are defined. 
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// values for biypcs iji GROUP_JTEM and GROUP_J^OINTMENT 



#dcfinc 


SCHEDULE_ITEM 


1 


#definc 


BROADCAST_ITEM 


2 


#defme 


RESCHEDULE_ITEM 


3 


#dcfiiic 


REMINDEILJTEM 


4 


^define 


FREE__TIME_rrEM 


5 


#defuie 


CANCEL_ITEM 


7 


#dcfmc 


REPLY_rrEM 


8 


#dcftnc 


MINUTES_JTEM 


9 


#define 


EVENT_J^CCEPT_rrEM 


10 


Mefittc 


EVENT_DECLINE_[TEM 


11 


#defifle 


EVENT_FORWARD_REPLY_jrEM 


12 


#define 


EVENr_FORWARD_SCHEDULE_rrEM 


13 


#definc 


EVENT_RESCHEDULE_REQUEST_nEM 


14 


Mefiiie 


TRANSFER_SEND_ITEM 


15 


#defme 


TRANSFER_^CCEPX-JTEM 


16 


#defuie 


TRANSFER_DECUNE_niSM 


17 


#dcfinc 


DlSTRIBUTE_rTEM 


18 


#defme 


BOOK_SCHEDUL£_rrEM 


19 


#deiuic 


BOOie_RESCHEDULE_rrEM 


20 


Meftnc 


BOOIL-CANCEUJTBM 


21 


#dcftne 


BOOK_ACCEPT_ITEM 


22 


#defuie 


BOOK^DECUNEJIEM 


23 
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As shown, the biypes data member can identify the item as 
a "Schedule" item, a "Broadcast" item, a "Reschedule" item, 
a "Reminder" item, a "Reply" item, a "Minutes" item, or the 
Uke. 

The bTimeZone data member stores an identifier uniquely 
identifying the time zone (e.g., Pacific Standard Time) that 
the dates are relative to. In this manner, the recipient user's 
system can automatically convert the times, if desired, to 
those relative to the time zone for that recipient. In a 
preferred environment, each appointment has its own time 
zone — typicaUy, the time zone in which the item was 
originally scheduled. The recipient systems convert this 
information to and from their own relative time zones, as 
needed. 
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Finally, the bLead and bLeadUnit data members store 
information describing a "lead" time or reminder. This 
information allows the system to send reminders to all 
participants. at a specified. interval. (e.g., three days) 

2. Each Recipient 

Each recipient involved with a group scheduling message 
is represented internally by a recipient data struaure: 
EACH_RECIPIENT. In an exemplary embodiment, the 
data structure may be constructed as follows. 



25 



typedef stxua 

char 
char 
long 
long 

DWORD 



szName[32]; 
sz£inail[64]; 
IID; 
1ID2; 

wHags; // type of c-maQ, Has free time, 
^1 sender or not, file flag ^ 
i// status flags, message or free^ime saved 
W point to free time file and ShortMsg mail 



DWORD wStatus; 

long IfData; ^// point t 

LPRECIPIENT-DAEA;; IpAttach; ' 

II HGLOBAL hAttach; // a REaPIENT_J)ArA structure 
} EACH^RECIPIENr, // 114 
typedef EAOLJIECIPIENT • LPEACH_RECIPIENT, 



As shown, the first data member, szName, stores a text string 
comprising the recipient's name (e.g., "John Smith" ). This 
is followed by another text string szEmail, \^ch stores the 
e-mail address for the recipient. Following the recipient 
name and e-mail address are two identifier data members: 
UD and 11D2. These IDs are used in combination to uniquely 
describe a particular recipient. 

Following the identifiers is a double word data member, 
wFlagis, storing recipient flags. The recipient flags indicate, 
for instance, whether the recipient has free time, whether the 
recipient accepts or declines, and so forth. In an exemplary 
embodiment, the status flags may be defined as follows. 



// type of e<inails, fax, or page in EACH_RECIPIENT stiucture 

#define TYPE_E-mafl AOL 0x0001 

Wcfinc TYPE_E-maU_COMPUSERVE 0x0002 

#define TYPE_E-mail_EXCHANGE 0x0004 

#define TYPE_E-mail_INTERNET OxOOOS 

^define TYPE_FAX 0x0010 

#define TYPE_PAGE 0x0020 

#dcfine TYPE_PHONE 0x0040 

^define TYPE_MAIUNO_UST 0x0080 
// type of recipient 

#dcfLne TYPE_PARnaPANT 0x0100 

#define TYPE_CC 0x0200 

#dcfine TYPE_ROOM 0x0400 

#define TYPE_EQUIPMENT 0x0800 
65 // also, TyPE_OfIHERS defiiicd below 
II misc. flags 
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#define IS_SENDER 

#dcfiac IS_SELF 

^define HAS_REaPIENT_DArA 

#define READ_IN_RECIPIENT_DArA 

#defme F_UST_DIKrY 

#dcanc 'nTE_OTHERS 

#dtlinc CARD_rD_SET 

#define rYPE_PAGE_ME 

#dcflnc REaPIENT_RECE[VED_FORWARD 

#defuie REaPIENT_SENT_FORWARD 
// Recipient status flag? 
// #defmc REaPIENT_STArUS 

#dcfiiie REaFIENT_FREE_TIME 

#defme RECIPIENT^FORWARD 

#dcfme RECIPIENT_E-inaiLj\DDRESS 

#dcftne REaFIENT__NAME 

#define RECIP[ENT_CARD_ID 

#dcfmc RECIP[ENT_MAIl^STXrUS 

#(iefine REQPIENT^ACCEPT 

#define REaPIENT_DECUNE " ' 

#defijic REaPIENT_KESCHEDULE_REQU[RED 

#dcfine REaPIENT_RESOURCE_CX)NFUCr 

#defuie REaPIENT_RESOURCE_TRANSFERRED 

#dcfin6 REaPIENT_RESOURCE_NOT_F0UND 

#defliie REaPIENT_JlESOURCe_CANCEUED 
// flags for resource events (from QzOOOlOOOO to 0x80000000) 

#dcfbc RECEIVE„DISTRIBUTE_RESOURCE QxOOOlOOOO 

#dcfuic RECEIVE„BOOK_RESOURCE 

*define SENT__BOOK_RESOURCE 

#defme RECEIVE_TRANSFEFL-RESOURCE 

#define SENT_TRANSFER_RESOURCE 

#defme IRANSFER.SUCCESSFUL 



QxlOOO 
0x2000 
0x4300 
0x8000 
QxOOOlOOQO 
0x00020000 
0x00040000 
0x00080000 
0x00100000 
0x00200000 

0x0001 
0x0002 
0x0004 
0x0008 
QxOOlO 
0x0020 
0x0040 
0x0080 

* 0x0100 

0x0200 
0x0400 
0x0800 
0x1000 
0x2000 



0x00020000 
0x00040000 
0x00080000 
0x00100000 
0x00200000 



invitation, or whether the recipient required rescheduling. 
Additionally, at this point, flag information is stored for 
resources, such as information indicating that the resource is 
not found, that the resource has been transferred, that the 
^ resource has been canceled, or that a conflict for the resource 
exists. 

Returning to the description of the EACH^RECIPIENT 
data structure, the next data member, IfData, is a pointer to 
10 a data block for the recipient; the data block stores free time 
information and a short message for the recipient. Finally, 
the EACH_RECIPIENT data structure stores a pointer, 
IpAttach, which points to a RECIPIENT_DArA structure. 
This structure will now be described. 

3. Recipient Data 

The RECIPIENT_DATA strucmre stores free time and 
-rescheduling -information for a particular recipient. In-an -^ 
exemplary embodiment, the data structure may be defined as 
20 follows. 



typedef struct 

DWORD dwFlags; // Reserved -- not used 

long IStart; 

long lEnd; 

DWORD dwRcschcduleStarttat 



25 



30 



35 



As shown, the information indicates the type of 
delivery — e-mails, fax, or page — desired for a particular 
recipient, thereby supporting methods for communicating 
with all types of recipients, other than just e-mail. For e-mail 
types, support is provided for multiple providers, including, 
for instance, America On-line (AOL), CompuServe, 
Microsoft Exchange, and the Internet For a recipient to be 
contacted via phone (i.e., type is TYPE_PHONE), the 
system adds an item to the user's "call list" — that is, a list 
of calls the user is to make (as shown at 440, in FIG. 4). A 
delivery type of "mailing list" indicates that the system is to 
process multiple recipients according to a mailing list 

The flags also indicate a recipient type. Arecipient can be, 
for instance, a "participant" (i.e., type is TYPE_ 
PARTiaPANT) — someone who is required to reply. A 
**CC* recipient (i.e., type is TYPE_CC), on the other hand, 
is not required to reply. Other types of "recipients" include 
"room," such as a conference room, and "equipment," such 
as a projector Finally, a recipient can be simply set to 
"others" for indicating that the recipient is other than that 
above. 

As a group scheduling item is associated with a list of 
recipients, it is helpful to further characterize recipients. lo 
this regard, a "sender" flag (type is IS_SENDER) is 55 
employed for indicating that the recipient is actually the 
sender. A "self* flag (type is IS_SELF), on the other hand, 
indicates that the recipient is "self* — that is, the same 
individual as the user. Other recipient-type information 
serves to further characterize the recipient. For instance, the 
"page me" flag indicates that this recipient is to be paged. A 
"sent forward** flag, on the other hand, indicates that this 
recipient has delegated the item to another user. 

Finally, the recipient flags store status information for 
each recipient. Status includes, for instance, information 
indicating whether the recipient accepted or declined the 



DWORD dwRescheduleEad[3;^ // 



reschedule request start 
date/time 

reschedule request end 
date/time 



LPSTR IpMsg; 
LPSTR IpFiecIline; 
void* IpNcxt; 
} REdPIENT-DATA; 

typedef RECIPIENX_DAiA • LPRECIPIEOT_DArA; 



40 



45 



50 



As shown, the first data member, dwFlags, comprises a 
double word data member storing flag or status information; 
it is currently not used. The next two data members, IStart 
and lEnd, indicate a free time range (e.g., next 30 days). 
Then, the next two data members, dwRescheduleStart and 
dwRescheduleEnd, store information specifying a resched- 
ule request start dateAime and reschedule request end date/ 
time, respectively. As each of these data members comprises 
an array of size three, these data members actually indicate 
three rescheduling alternatives. 

The next data member, IpMsg, comprises a pointer to a 
text string storing a message associated with the reschedule 
request (e.g., "Sorry, I am in Chicago next week; please 
reschedule."). This is followed by a pointer, IpFreeTime, 
which points to a block describing the free time for the 
recipient (i.e., information employed for displaying a Free 
Tune report for this recipient). Finally, the data structure 
includes a ''next" pointer, for pointing to a subsequent 
REaPIENT_J)ArA structure. 

Each REaPIENT_DArAsUiicture, when saved to file, is 
associated with a header: RECIPIENT_DATA_HEADER. 
In an exemplary embodiment, the header may be con- 
60 structed as follows. 



typedef struct 
{ 

DWORD dwFlagp; 
65 UINT nMsgs; 

UtNT oFreeTimes; 
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long IStart; 
long lEnd; 

DWORE> dwReschcduleStart[3]; // reschedule request 

stait date/time S 

DWORD dwRescheduleEnd[3]; // reschedule request 

end datc^tinte 

} RECIPIENT_DArA_HEADER; 
typedef RECIPIENT_DArA_HEADER • 
LPRECIPIEKr_DArA_HEADER; 
' 10 

The header includes data members the same as or similar to 
those described for REaPffiNT_DArA. AdditionaUy, the 
header stores a number of messages, nMsgs, and a number 
of free times, nFreeTimes. 15 

Also stored is a footer: RECIPIEISni.DArAJOOTER. 
This may be constructed as follows. ^ 



typedef struct 20 
{ 

DWORD IfDala; // -1 if no next item. 
} REaPIENT_DArAJ'O0TER; 
typedef RECIPIENT_DAEA..HEADER • 
LPREaPIEOT_DArA^JiEADER; 
25 

The footer simply comprises a single data member, IfData, 
which serves to indicate whether a "next*' recipient data item 
exists (in a chain of recipient data records). 
4. Group i^pointment 30 
At run time, a memory block or buffer is allocated for 
storing context information. This buffer is organized into a 
GROUP_j\PPOINTMENT structure, for describing a par- 
ticular group appointment. In an exemplary embodiment, 
this data structure may be constructed as follows. 



typedef struct 




DWORD 


dwEventlDl; 


DWORD 


dwEvcntrD2; 


DWORD 


dwFromDateTime; 


DWORD 


dwTbDateHmc; 


DWORD 


dwOldFromDatcTimc; 


DWORD 


dwOIdTo DaleUme; 


DWORD 


dwReecheduleStort[3]; 


DWORD 


dwRcschcduleEnd[3]: 


DWORD 


dwSendReceive; 


HANDLE 


hUxt; 


HANDLE 


hRegprding; 


HANDLE 


hRecipient; 


LPSTR 


IpMeetingNote; // meeting note file name 


LPSTR 


IpShortMsg; 


LPSTR 


IpDelegateMsg; 


LPSTR 


IpFreellme; 


int 


nbDelegjite; 


int 


nis Resource; 


HANDLE 


hForward; 


WORD 


nlbxts; 


WORD 


nReg^rdings; 


WORD 


nRecipients; 


DWORD 


wFlags; //READ_IN 


DWORD 


wPlagsZ; 



short 


nPagcHour; 


short 


nPageMin; 


BYTE 


bLeadHour, 


BYTE 


bLeadMin; 


BYTE 


bReminderLead; 


BYTE 


bRemindcrUnii; 


BYTE 


bTlmeZone; 


BYTE 


biypes; 


inl 


albne; 


DWORD 


IfData; // 42 


tnt 


nResourceStatus; 


char 


szRcsourocSamc[64i 


char 


szLocation[64]; 


char 


szCity(64]; 


char 


szSenderName[32]; 


char 


szSenderE-mait(64]; 


int 


nSenderE- mailXype; 


char 


52AttachFilc[ PArHMAX+4t 


EACHLREaPIENT PageMe; 




int 


cPIaoeLists; 


// IPSTR 


IpTZ; 


// int 


nTZ^ 



} GR0UP_APPOINTMENT, // total 136 bytes 
typedef GR0UP.^P01NTMENr • LPGROUP_jU»POINTMENTi 



This temporary, in-memory data structure (i.e., it is not 
saved to disk) largely comprises data members taken from 
the previously-described data structures. Additionally, 
however, the data structure stores information further 
describing any delegation. For instance, the IpDelegateMsg 
data member points to a delegate message text string. This 
allows one recipient to send a message to a delegatcd-to 
recipient, yet .hot have that text string message returned to 
the originator of the invitation. Additionally, delegation is 
supported by the szSenderName and szSenderE-mail data 
members. This information indicates who the delegated to 
recipient should respond to — that is, the originator of the 
invitation. - 

Group Scheduling Methodology 
1. Schedule Group Event 

With an understanding of the internal day structures 
employed, methods of operation may now be examined in 
further detail. Group scheduling begins with a request to 
schedule a group event. This request results from user input 
occurring at the user interface, as illustrated at step 1001 in 
FIG. 10. Actual operation of the user interface itself, such as 
processing menu selections and user input at edit fields, may 
be done in a conventional maimer using standard windows 
graphical user interface (GUI) methodology. 

Once the user input has culminated in a request to 
schedule a group event, the request is processed by the group 
scheduling module or engine 910 (of FIG. 9). This module 
internally invokes a Schedule_Group_Event method. In an 
exemplary embodiment, the Schedule_Group_Event han- 
dler or method may be constructed as follows (again, using 
the C/C++ programming language). 



1: 

2: Schedule a following type of group events: 
3: - Normal group event (reply required) 

4: - Broadcast group event (no reply needed) 
5: - Reminder 

6: • Reschedule 
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- Free time 

- Cancel meeting. 



10: int SchcduIe_Group_Event (LPGROUP_APP0INTMENT IpNew, 

11: int nAddlbUst, int nAddlbAppointment, int nFromCalendar, 

12: LPSTR IpInBuf, int nlnSize) 

13: { 

14: GROUP_rreM Gioupttem; 

IS: LPSTR IpMessage - IpInBuf; 

16: int nlndex = -1; 

17: 

18: if (IlpMcssagc) 

19: { 

20: IpMessage - AllocLockBufferPtr (NOTETEXTSIZE * 3); 

21: nlnSire - NOTCTEXTSIZE * 3; 

22: } 
23: 

24: if(!lpMes5age) 

25: return FALSE; 

26: ■ - ' 

27: nstartOroupEvcnt - TRUE; 
28: 

29: // Save to appointment list in Calendar module. 

30: if (IpNcw — >hRccipicnt && IpNcw — >nRccipi6nts) 

31: { 

32: // get send and receive time. 

33: if (IpNcw— >b'IVpc» — SCHEDULE_JTEM || ^New— !>bTVpcs 

34: = BROADCAST_JTEM 1 1 IpNew— >b'IVpes 

35: — RESCHEDULE_ITEM 1 1 IpNew— >b'IVpes — CANCEl^ITEM) 

36: lime (&(lpNew— odwSeadSeoeive)); 

37: 

38: // - add call items to call list. 

39: if OpNcw^blVpes — SCHEDULE-ITEM 

40: 1 1 IpNew— >b'iypes = BROADCAST_JTEM) 

41: Insert_Qdls__Oalendar (IpNcw); 

42: 

43: // - add send letter to todo list. 

44: if (IpNew— >b'IVpes = SCHEDULE_rrEM 

45: 1 1 IpNew— >b'I>pes — BROADCAST_ITEM) 

46: Insert_1bdo8_Xalendar (IpNew); M.. 

47: ^ 

48: // ad4/edit/delete calendar item W 

49: if (loFromOilendar) 

50: { 

51: if ((IpNew— >b'I>pes ^ SCHEDULE_rrEM 

52: 1 1 IpNew— >blSpes — BROADCASr_rrEM) 

53: Sl& nAdcfTo^ipouiitment) 

54: { 

55: if (!(lpNcw— >wFIag5 & UNBOOKED_EVENT)) 

56: AddNcw>^pointment_FiomGROUP OpNew); 

57: // AddNewGroupAppointment HpNew); 

58: } 

59: else if (IpNcw— >b1\pes —i RESCHEDU1JE_JTEM) 

60: { 

61: // #### Reschedule Appointment 

62: aia[igeExistAppointment_FromGROUP (IpNew); 

63: } 

64: else if OpNew-H>bTVpes — CANCEl^lTEM) 

65: { 

66: // #### delete appointment 

67: DeleteExistAppointment_FrcmGROUP (IpNew); 

68: } 

69: } 

70: 

71 : // add item to GROUP event data base. 

72: if (nAdtflbList) 

73: { 

74: RcsoIveAllMaOingLists (IpNew); 

75: ifl[IGROUP_>Vppointment_1b_GROUP JtemQpNew, AGroupItem)) 

76: { 

77: UnlockFrecBufferPtr OpMessage); 

78: letum FALSE; 

79: } 

80: GroupItem.wFIag? =- READ_IN_MAIN | READ_IN_AnACH; 

81 : Group[tem.wFlag^ =■ SCHEDULED_EVENT, 

82: Gro«pItem.wFli^2 — EVENT_QUEUEJTEM; 

83: if (lIsBroadcastiype (&GioupItem» 

84: { 

85: ResolveAlIExchangeMailingLtsta (&CTOUpItem>; 

86: } 
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87: 



88: ScaiiForSel£_SetAooept (fiGronpItem); 

89: // actual call to add item to GROUP event database 

90: nlndex 

91: - AddOneGroupItein ( NULL, AGroupItem, 

92: SCHEDULED_EVENT, 

93: Get CUrrent_SortFlag ( )); 

94: // . . . DEBUG 

95: } 

96: // empty else case . . . 

97: // Now COMPOSE MESSAGE 

98: if (l(lpN6w— >wFlags & SEND_I.ArER)) 

99: { 

100: if (IpNcw— >b1Vpe8 — SCHEDULE^ITEM) 

101: { 

102: GomposeScheduleMessa^ (IpNew, 

103: MSG_SCHEDULE, IpMessage, nlnSize); 

104: } 

105: else if (IpNew— >bTypes = BROADCASr_JTEM) 

106: { - 

107: GbnqjoseScheduleMessage OpNew, MSG_BROADCAST, 

108: IpMessage, nInSize); 

109: } 

110: else if OpNew— >bTVpcs — REMINDER_rrEM) 

111: { 

112: CbmposeScheduleMessage (IpNew, MSG_JIEMINDER, 

113: IpMessage, aInSize); 

114: blsReminderMsg = TRUE; 

115: } 

116: else if (IpNew-— >b'IVpes — RESCHEOULB mEM) 

117: { 

118: OomposeScheduleMessage (IpNew, MSO_JlESCHEDULE, 

119: IpMessage, nlnSize); 

120: } 

121 : else if OpNcw— >b1Vpe8 — CANCEUjrEM) 

122: { 

123: Cbiiq)oseCancelMessage (I[^ew> IpMessage, nlnS^); 

124: } 

125: 

126: // - send email; 

127: Send^OL^EmaU QpHew, IpMessage); 

128: Sc]id_Cbii]puSeive_EinaiI OpNew, IpMessage, FALSE); 

129: Send^JEzchaoge-JEmaa (I^New, IpMessage, FALSER 

130: Send_Jotcniet_EinaU (IpNew, IpMessage, FALSE); 

131: 

132: 

133: // - send fax; 

134: Send_Gn>upJpax (IpNew, IpMessage, FALSE); 
135: 

136: if (OpNew^>b'IVpes — SCHEDULE_rrEM) ( | 

137: (IpNew— >bTypes — BROADCAST_ITEM) 1 1 

138: (IpNcw— >bTypes — RESCHEDULE-jraM) 1 1 

139: (IpNcw— >bTypc8 = CANCEL-JTEM)) 

140: { 

141: int nLen - Istrlea OpMessage); 
142: 

143: Loadstring (hGardfUelnstance^ 

144: IDS_THIS_IS_RESOURCE, IpMessage + nLen, BUF_LEN); 
145: 

146: Seiid_CompuScrve_Email (IpNew, IpMessage, TRUE); 

147: Send_Exchange Email OpNew, IpMessage, TRUE); 

148: Send_Intcmel_Email (IpNcw, IpMessage, TRUE); 

149: Scnd_Group_Fax (IpNcw, IpMessage, TRUE); 

150: } 
151: 

152: // - send page; 

153: Send_Group_Page (IpNew, FALSE); 

154: blsReminderMsg « FALSE; 

155: } 

156: fecbeduledDifty ° TRUE; 

157: } 

158: else 

159: { 

160: AddNewAppointment FromGROUP (lpNew>, 

161: } 

162: if(IlpInBuf) 

163: UnlockFreeBufferPtr OpMessage); 
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164: nStartGroapEvent ■> FALSE; 
16S: 

166: letomTRUE; 
167: } 



Oine numbers added above to aid in the following descr^tion) 



This method is invoked after the user has completed UI 
data entry. It serves to schedule one of the following types 
of group events: Normal group event (reply required), 
Broadcast group event (no reply required), Reminder, 
Reschedule, Free Time, or Cancel meeting. 

The parameters required for the method are set forth at 
lines 10-12. TTie first parameter, IpNcw, references a new 
group appointment data stmcturc (described above). The 
second parameter, nAddToList, indicates that this group 
event should be added to the group scheduling database. The 
third parameter, nAddToAppointment, indicates whether the 
event should be added to the user's appointments (listed in 
the user's calendar). The fourth parameter, nFromCalendar 
indicates that this request is originating firom the user's 
calendar, for example, as a result of a drag-and-drop event 
occurring in tte calendar. The first two parameters, IpnBuff 
and nSize, characterize a passed-in memory buffer; the 
memory buffer is typically used for storing message strings. 
At lines 14-16, the method initializes local (stack) variables. 
At lines 18-25, the method attempts to allocate a memory 
buffer for storing a message. If a buffer cannot be success- 
fully allocated, the method returns "false*' at line 25. At line 
27, the method initializes a global variable, 
nStartGroupEvent, to the value of "true." 

Starting at line 29, the method will undertake to save the 
group event to the appointment list in the calendar module. 
This occurs as follows. At line 30, the method tests whether 
there are recipients — that is, whether this is a "group" 
appointment. Otherwise (i.e., the condition at line 30 is 
(fake), the event is instead a "local" appointment. Between 
lines 32 and 69, the method tests group appointment flags for 
determining its course of action. At lines 32-36, for instance, 
if the event is a "Schedule" item, a "Broadcast" item, a 
"Reschedule" item, or a "Cancel" item, the previously- 
described dwSendRecieve time stamp is updated at line 36. 
At lines 38-41, the method adds a Schedule or Broadcast 
item to the user's call list. In a similar manner, at lines 
43-46, the method adds a Schedule or Broadcast item to the 
user's "to do" list. The "insert calendar" call serves to call 
into the calendar module 920 (of FIG. 9). 

At lines 48-49, the method tests whether the event request 
originated firom the calendar. If not, then the method must 
add the event to the appointment list, if the requested event 
is a Schedule or Broadcast item. Specifically, the method 
invokes an AddNewAppointment^J^romGROUP subrou- 
tine at line 56. Otherwise, the method tests whether the event 
is a Reschedule item (at line 59) or a Cancel item (at line 64). 
For a Reschedule item, the method changes the existing 
appointment, at line 62. For a Cancel item, on the other 
hand, the method deletes the existing appointment, at line 
67. 

At lines 71-95, the method undertakes to add the event 
item to the group scheduling (event) database 950 (of FIG. 
9). Specifically, the method tests the nAddToList parameter, 
at line 72. If this is set to "tme" (i.e., greater than 0), the 
method proceeds to convert the group appointment into a 
group item, resolving all recipients on any mailing lists. The 
actual call to add the item to the database occurs at lines 
89-93, where one group item is added. 



Starting with line 97, the method will now undertake 

10 composing of the message for notifying recipients of the 
group scheduling event. At line 98, the method tests a 
SEND — LATER flag, which indicates whether the schedul- 
ing message is to be sent later. If the message is not to be sent 
later (i.e., the "if statement at line 98 evaluates to "true"), 

15 then the group scheduling event message must be composed 
now. In such a case, the method will proceed to compose and 
send a message, at lines 99-155. Steps of the method for 
composing and sending the message will be described next. 
Lines 100-124 set forth a sequence of "else if' case-like 

20 statements which switch on the item type. At line 100, for 
instance, if the item is a Schedule item, the method invokes 
the composer at lines 102-103, for composing a Schedule 
message (MSG SCHEDULE). If, instead, the item is a 
Broadcast item, tested at line 105, the method invokes the 

25 composer at lines 107-108, for composing a Broadcast 
message (MSG— BROADCAST). For a Reminder item, 
tested at line 110, the method invokes the composer at lines 

112-113, for composing a reminder message (MSG 

REMINDER). For a Reschedule item, tested at hne U6, the 

30 method invokes the composer at lines 118-119, for com- 
posing a reschedule message (MSG_RESCHEDULE). 
Finally, if the item is a Cancel item, tested at line 121, the 
method invokes the composer at line 123, for composing a 
cancel message. The foregoing steps, therefore, invoke an 

35 appropriate handler in the composer 912 (of FIG. 9) for 
creating an appropriate message. The message itseff is stored 
in the memory buffer pointed to by IpMessage — the memory 
buffer allocated at lines 18-25. After the task of composing 
the message is done, the method proceeds to send the 

40 message using the appropriate transport for each recipient. 
At lines 126-130, the method invokes the e-mail module 
or manager for transporting the message over available 
services: America On-Line (handler invoked at line 127, 
CompuServe (handler invoked at line 128), Microsoft 

45 Exchange (handler invoked at line 129), and Internet 
(handler invoked at line 130). As shown, each handler 
invocation passes a pointer to the GROUP_ 
APPOINTMENT data structure as well as a pointer to the 
message buffer (which holds the just-created group sched- 

50 uling event message). As shown, a Boolean parameter is 
passed with the value of "false" for indicating that the 
message is not for a resource (which requires a slightly 
different format). For each handler invocation, the e-mail 
module will enumerate the recipients for the respective 

55 services and post group scheduling event messages accord- 
ingly. 

At lines 133-134, the method invokes a fax handler for 
sending facsimile transmissions to the recipients which are 
preferably reached via that mechanism. Faxing from the 
60 computer can be done in a conventional manner, using a 
"Fax modem" and built-in Fax support (e.g., in Microsoft 
Windows® 95, available from Microsoft Corp. of Redmond, 
Wash.). 

At lines 136-150, the method essentially repeats the 
65 foregoing steps of invoking e-mail and fax handlers, except 
that here the process is undertaken for a resotu^ce. The 
process is essentially the same except that at lines 141-144 
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the method modifies the just-created message (stored in the 
memory buffer) for adding an identifier indicating that the 
group scheduling event is for a resource. At lines 152-153, 
the method invokes a SendGroupPage handler for process- 
ing any request to page a recipient (or the user himself or 
herself). At lines 154 and 156 local cleanup is performed. 

At Une 158, an "else" statement is defined. This statement 
is reached in the event that the message is to be sent later 
(i.e., the "if' statement of line 98 evaluates to "false"). In 
such a case, the method simply adds a new appointment, at 
line 160. Steps are not undertaken at this point to compose 
and/or post a group scheduling event message. Finally, the 
method performs local cleanup, such as freeing the message 
buffer, at lines 162-163. After resetting the nStartGroupE- 
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calendar with the embedded calendar. The synchronization 
generic in nature, so that it can be extended to any data 
object which is capable of synchronization. 

S b. Message Body 

Following the signature and message-type is (if required) 
a message body. Here, the system includes specific data 
items which characterize the scheduling event. The message 
10 body for Schedule and Broadcast message-types is exem- 
plary in this regard. In an exemplary environment, a mes- 
sage body for these message-types may be constructed as 
follows: 



<From Date Tirno 
<To Date Ttmc> 



YY/MM/DD HH;MM 
YY/MM/DD HH:MM 



<Location> :- Place name where the meeting will be held 

<CLty> :** City name where the meeting will be held It is related to Time Zone. 

<'Iime Zoiie> <'nme zone name where appoinimeat time is based on> 

<Attributes> <AIarm> 

<EveatIDl> A unique ID for the event, 

<Bveiit[ID2> :- The second part of the ID. 

<Subject> :- <Message text>-</Subject> 

<Message Content> <Regaidiag textx/Messagc ContBnt> 

<Participants> :« ''Name; Email address; Email TypcT t'fame; Email Address; 

Email lype" </Participants> 

<CC> :- ''Name; Emafl address; Email l^e" ''Name; Email Address; Email Type'* 
<JCC> 

<:Room> : = ''Name; Email address; Email Type" "Name; Email Address; Email Type" 
<fRoom> 

<Equipment> > ''Name; Email address; Email lype" "Name; Email Address; Email 

Type" 

<</Equipment> 

~ i == 

vent global flag, at line 164, the method returns "true," at As shown, the message body includes data items which 
line 166, whereupon the method is completed. J 35 correspond to the previously-described internal data struc- 
2. Composing Messages . . ^ tures. For instance, the group scheduling event is character- 
To understand methods of the present mvention for com- • JL «£. « J «* 11 J ^ J ^- 1 

• i_ 1 XL 1 . L . . ized by a from and a to date and time, a location, a citv. 

posmg messages, it is helpful at the outset to examme group »^ « uai» ouu umc, a iu».aiiuu, a f^ny, 

scheduling formats employed by the system for creating ^ ^ ^"^^^^ ^ identified by the 

messages. In general, messages are created using delimiters, previously-described two-part event ID. The message body 

thereby, avoiding position dependency of particular infor- concludes with a list of e-mail addresses, including 

mation within a message, addresses for participants, "CC recipients, and resources 

a. Message Formats (divided into "room" and "equipment** subtypes). Each of 
In an exemplary environment every message mcludes a jj^^^ ^se a list of e-mail addresses. 



The message body for a reply message, on the other hand, 
is constructed as follows. 



signature and a message type, which may be constructed as 
follows: 

<Product Signature> :- <ISK> (or <SIS>) 

<Mcssagc lypo ;- <Schedule\Broadcast\Reply\Free Time\ „ , ^ ..... 

RcmindcrUleschedu!e\McetingNolc\C&i«l\Reairriiig\NewResoui^^ 50 ^^'P^^?^^ <Acccpt\Dcdmc\Reschcdiile Reqmrcd\Slcep\ 

ResoutceVActionVSynchronizatiDn* Fonwird\Resource\Free Tmie> 

<Forward Tb> :- <NBmc; E-mail address; Emad Typ6> 

</Forward 'Ib> 

As shown, the message inchides the previously-described ^ ^!ff^*£?^*' "^''"^^ ^^,w«.^ 

*, ^ c^ii J if .'1 . rwn. <From DaU rime> YY/MM/DD HH:MM 

Signature followed by a particular message-type. The ^DateTtme> yy/mm/dd hh:MM 

message-type itself can be aoy one of the following: 55 » 

Schedule, Broadcast, Reply, Free Time, Reminder, <EventIDl> >- A unique ID for the event 

Reschedule. Meeting Note, Cancel, Recurring, New ^^^""^^^ TTic second part of the ID. 

Resoui^, Resource, Action, and Synchrooization. The <Sho^t Message> :- cShort messago^ort Messase> 

"Action" message-type supports workflow applications. 

Here, the message serves as a "to do" item or task for one 60 

or more recipient users. The "Synchronization" message, 00 Again, the message body includes data items corre^onding 
the other hand, serves to synchronize two or more data ^ the previously-described data members in the group 
objecu, such as user calendars. Recall that a data object scheduling internal data structures. A reply includes, for 
characterizing a calendar (e.g., free time data objea) can be instance, a reply type, such as "Accept," "Decline," 

imbedded within a message. A Synchronization message- 6S "Reschedule required," or the like. In the event that the 
type, therefore, exchanges calendars and instructs the recipi- replying user has delegated the event, the delegated-to user's 
ent system to automatically synchronize the recipient's address is provided in the ''forward to" field. If the reply 
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request rescheduling, rescheduling date and time informa- 
tion is included. For this type of niessage, the message also 
includes a file attachment providing further information for 
(e.g.. Free Time report). Finally, the message includes the 
two-part event ID, so that the reply can be matched up with 
the original invitation. Any message provided by the reply- 
ing user is transmitted in the message field, ""short message/' 



36 



The "sleep" message -type is provided for those users who 
are on vacation. Exemplary message bodies for other mes- 
sage types are appended herewith as Appendix A. 
c. Methodobgy for Composing Messages 
In an exemplary environment, a method for composing 
scheduling event messages, ComposedScheduledMessage, 
may be constructed as follows. 



1: / 

2: This &iictioa is called for sdiedule a: 

3: - Schedule meeting 

4: - Broadcast meeting 

5: - Reminder 

6: - Reschedule 

7: 

8: Meeting message fonnat is: 
9: 

10: .<Message lypo message type nameVrtn . . 

11: <0!d Date Tlme> yy/mm/dd hh:nim\i\n (if it's a Kschedule message) 

12: <From Date Tune> yy/moi/dd hh:mm\r\a 

13: ^ Date Time> yy/mm/dd Ub:mm\i\a 

14: <Location> location name\i\n 

15: <fnme Zone> time zone value\r\n 

16: <Attributes> "attribute" "attribute" . . . \I^n 

17: <EvenUDl> EvcntlDl value string\r\n 

18: <EventID2> Evcnt[D2 value string\rtn 

19: <Subject> Ibxt body</Subject>\r\n 

20: <MessagB Content> Regarding body</Message Content>\i\n 

21: 

22: 

23: - 

24: int CbnqjoseScheduleMessagp (LPGROUP_J\PP(^NTMENTlpGn>up, 

25: int nMessageType, 

26: LPSTR IpMessage, 

27: int nSize) 

28: { 

29: char szrLeld[BUF_LEN+l], szSpace[2l 

30: szReturn[5], 8zrimelBUF_LEN+l]; 

31: int nIsRcschedule - FALSE, nIsBroadCast - FALSE; 

32: LPSTR IpBuf; 

33: BYTE biypes; 

34: 

35: szSpace[0] - ' '; 

36: 5zSpace[l] - 0; 

37: GetRcturnNcwlinc (szRctura); 
38: 

39: if ((nMessagcTVpc «~ MSG_DISrRIBUTe_RESOURCE) 

40: I I (nMcssagciypc — MSG_TRANSFER_RESOURCE)) 

41: { 

42: LoadGenericHeaderMessage (IpMessagp); 

43: } 

44: else 

45: { 

46: if (nMessageXype — MSG_SCHEDULE 1 1 

47: nMessagcTVpc »= MSG_REMINDER 1 1 

48: nMessagc1\pe «- MSG_BROADCAST j ( 

49: nMessegeiype -- MSG_RESCHEDULE) 

50: Load^SICllMessage^Headei (IpOioup, IpMessage, nSize); 

51: } 

52: 

53: 

54: /• 

55: 

56: This message was generated by Internet Sidekick. 

57: * If yon have Internet Sdektck instaUed on your system: 

58: - Please ignore this message and do not delete ii £rom you inboK. 

59: - Internet Sidddck will automatically process it next time you 

60: Send/Receive messages or during the next scheduled Flash Session. 

61: 

62: * If you do not have Internet Sidekick: 

63: - You can reply to this invitation using your e-mail software. 

64: lype an X next to either Aoc^ or Decline below, so it reads 

65: [X] Accept or [X] Decline. 

66: • You can ako enter a short message as part of your reply to the 

67: initiator in the blank section between <BEGIN REPLY MESSAGE> and 

68: <END REPLY MESSAGE>. 

69: - When you reply from your E-mail product, make sure thai the reply 

70: includes the whole original message body including the section 



01/08/2004, 



EAST Version: 1.4.1 



6,016,478 

37 38 

-continued 



below the heading, For Internet Sidekick Use Only. Also do not 
modify or delete the Subject of this c-ouil message. 

• Fbr further infonnatton on how to procure it, please visit 
Starfish Software's web site at: 

<ht^>;//www.8tarfishsoftwBre.coiD>. 



i From: (Initiator) 
Date/Itmc: {Datc/Ume} 
Duration: {Duration} 
Tune Zone: {Tune Zone} 
Location: {Location} 
City/Oountry: {Qty} 

Subjcxl: {Subject} 
Messa^: {Message} 



<BEGINREPLY> 
Your Reply: 

[ ] Accept 
[ ] Decline 
<END REPLY> 

Reply Message: 

<BEGIN REPLY MESSAQE> 

<END REPLY MESSAGE> 



The section below is for Internet Sidekick Use Only. 
Please, do not edit or delete any of the information 
below this line. 



// append <Message 'IVpe> and spaict 
LoadStiittg (hCaidiilelnstancey 

IDS_SKWGROUPJ^ESSAGE_TyPE_JD, 

IpMcssage+lstilenOpMessage), nSize); 
Istrcat (IpMessage, szSpace); 

// append Schedule, Broadcast, Reminder, Reschedule 

switch (nMessa^l^pe) 

{ 

case MSO_SCHEDULE: 

LoadStiing (hCardfilelnstance, 

IDS_SKWGROUP_SCHEDULE, szField, BUF_LEN); 



case MSG^ROADCASrr 
LoadStiing (hCardfilelnstance, 

IDS_SKWGROUP_BROADCAST, 

szFicld, BUF_LEN); 
nIsBioadCast - TRUE; 
break; 

case MSO^REMINDER: 
LoadStiing (hCardfilelnstance, 

IDS_SKWGROUP_REMINDER, szFicid, BUF_LEN); 

break; 

case M$G_RESCHEDULE: 
LoadStiing (hCaidfilelnstance, 

IDS_SKWOROUP_RESaffiDULE, szField. BUF_LEN); 
nIsReschedule « TRUE; 
break; 

case MSO_RESOURCE: 
LoadStiing (hCardfilelnstance, 

tDS_SKWGROUP_RESOURCE_SCHEDUlJE, 

srFicld. BUF_LEN); 
break; 

case MSG_DISrRIBUrE_RESOURCE: 
LoadStiing (hCardfilelostancc, 

IDS_SKWGROUP_NEW_RESOURCE, 
szFicld, BUF_LEN); 

break; 

case MSG_RESOURCE_RESCHEDULE: 
LoadStiing (hCardfilelnstance, 

IDS_SKWGROUP_JlESOURCE_RESCHEDULE, 
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151: szField, BUF^LEN); 

152: brealc; 

153: case MSG_RESOURCE_CANCEL: 
154: LoadString (hCardfilelnstance, 

155: IDS_SKWGROUP_RESOURCE_CANCEL» 
156: szFicId. BUF_LEN); 

157: break; 

158: } 

159: AppendString (IpMessage, szField, 

160: szRetum, NULL, NULL, NULL, nSize); 

161: 

162: if (nIsReschedule) 

163: { 
164: /• 

165: if it IB a icschedule operation 

166: then insert original dateAime 

167: V 

168: OetOmOlmeStcing OpGroup — xlwOldFromDatcTimc, 

169: IpGroup — ^>bTlmeZone, szlline, BUF_LEN); 

170: ■ • LbadStiing (HCardfilelastaixs; * 

171: IDS_SKWGROUP_OLD_DAre_TiME, 

172: szField, BUF_LEN); 

173: ^jpendString (^Message^ szField, 

174: szSpacc, szlimc, 

175: szRetum, NULL, nSize); 

176: } 

177: 

178: // Append from and to dateAime 

179: LoadString (hCaidfilelnstance, 

180: IDS_SKWGROUP_FROM_J)AI1E^HME, 

181: szFidd, BUF^UEN); 

182: GetGmtHmeString (^iGroup — >dwFromDateTinie, 

183: IpGronp— >briincZonc, s^Ilme, BUE_LEN); 

184: AppendString (IpMessage» szField, 

185: szSpace, szTime, szRetum, NULL, nSize); 

186: 

187: LoadString (hCaidfilelnstance, 

188: IDS_SICWGROUP_T0_DArE_TIME, szField, BUF_LEN> 

189: GetGrnOimeString (IpGroup — >dWToDBteTime, 

190: IpGroup — >bTiineZcne, sillme, BUF_XEN); 

191: .^ipendString (IpMessage, szField, 

192: szSpftce, aaOlme, szRetum, NULL, nSize); 

193: 

194: // Append city and country information 

195: LoadString (hCardaielnstance, 

196: IDS_SKWGROUP_Cm; szFicld. BUF_LEN); 

197: J^ipendString (IpMessage, szField, 

198: szSpace, ^jGtoi^) — ^>fizCity, 

199: szRctum, NULL, nSizc); 

200: 

201: // Append location and time zone information 

202: // <Location> location name\K\n 

203: // 4^nme Zone> time zone yah]e\i\n 

204: // IDS_SKWGROUP_TIME_ZONE, "<Tmic Zono" 

205: // IDS_SKWGROUP_LOCAnON, *<Location>" 

206: LoadString (hCardfilelostance, 

207: IDS_SKWGROUP_LOCAnON, szField, BUF_LEN); 

208: Af^ndString (IpMessage, szHeld, 

209: szSpace, lpOT0iq>— >szLocation, 

210: szRetum, NULL, nSize>, 

211: LoadStnjig (hCardfUcInstance, 

212: IDS_SKWOROUP_T[ME_ZONE, szField. BUF _LEN); 

213: // nvalue » GetTimeZone\^lue (IpGroup); 

214: _itoa ((int)lpGroup— >b'nme2Sone, a^Time, 10); 

215: AppendString (IpMessage, szField, 

216: szSpace, szTime, szRetum, NULL, nSize); 

217: 

218: // Append attributes 

219: // <Attributes> "attributed' "attribute" . . . \rtn 

220: // IDS_SKWGROUP_jaTRIBUTES, -<Attributes>" 

221: LoadString (hCaidfilelnstance, 

222: IDS_SKWGROUP..jVITRIBLrrES, szField, BUF_LEN); 

223: GetAttributeString (IpGroup, szTune, BUF__LEN); 

224: AppendString (IpMessage, szField, 

225: szSpace, szTune, szRetum, NULL, nSize); 

226: 

227: // Append Event [Dl 

228: // <EventIDl> EvcnaDl value Btring\rtn 

229: // IDS_SKWGROUP_EVENTID_l, -<EventIDl>" 

230: LoadString (hCaidfilelnstance, 
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231 : IDS_SKWGROUP_E VENTID_1, szFicld, BUF_IJEN); 

232: Jloa ((long)lpGroup— xiwEvcntlDl, szTunc, 10); 

233: AppcDdString (IpMessage^ szFteld, 

234: szSpace, sfTime, szRetum, NULL, nSize); 

235: 

236: // Append Event [D2 

237: ;/ <EventID2> EvcnaD2 value Btring^^\ll 

238: // IDS_SKWGROUP_PVENTID_2. "<EveiitID2>" 

239: LoadString (hCaidftlelnstaoce, 

240: IDS_SKWGROUP_EVErmD_2, szField, BUF_LEN); 

241: _Jtoa ((bag) IpGroup— >dwEventID2, szTIme, 10); 

242: AppendString (IpMcssage, szFicld, 

243: szSpace, szTime, 

244: szRetum, NULL, aSizc); 

245: 

246 : if OpGroup— >wFlag$ & EVENT_FORWARDED) 

247: { 

248: EACH_3EaPlENT Rcdpicnt; 
249: 

250: ' //append sender's name and sender's email address 

251 : if (OetScndcrlnfo GpOioup, ARedpicnt, IS_SENDER) >« 0) 

252: { 

253: LoadString (hCardfilelnstance, 

254: IDS_SKWGROUP_SENDER_NAME, 

255: szField, BUF_LEN); 

256: AppendString (IpMessage, ezField, 

257: szSpace, Recipient, szName, 

258: szRetum, NULU nSize); 

259: LoadString (hCardfilelnstance, 

260: IDS_SKWGROUP_SENDER_EMAIL» 

261: szField, BUF_XEN); 

262: AppendString (IpMessage, szField, 

263: szSpace, Recipient, azEmail, 

264: szRetum, NULL, nSize); 

265: } 

266: // append forward flag "1" 

267: LoadString (hCardfilelnstance, 

268: IDS_SKWGROUP_JS_DELEGArE, 

269: szField, BUF_LEN); 

270: i^jpendString (IpMessage, szField, szSpace, 

271: "1", szRctum, NULL, nsize); 

272: } 

273: 

274: // Append Text 

275: // <Subject> Text body</Subject>\i\n 

276: // IDS_SKWGROUF_TE?Cr, "<Subjcct>" 

277: // IDS_SKWGROUFjaND_TEXT, -</Subjcct>'' 

278: if (IpGroup— >hText) 

279: { 

280: LoadString (hCardfilelnstance, 

281: IDS_SKWGROUP_TEXT, 

282: szField, BUF_LEN); 

283: LoadString (hCardflMnstance, 

284: IDS_SKWGROUP_END_TEXT, 

285: szTimc, BUF_LEN); 

286: IpBuf » GlobalLock (IpGroup— >hltxl); 

287: AppendString (IpMessage, szField, 

288: szSpacc, IpBuf; 

289: s^Ilme. szRetum, nSize); 

290: GlobalUnlock (IpGioup— >h'nxt); 

291: } 

292: 

293: // Append Regarding 

294: // <Message CDntent> Regarding body^Message Cont6nt>\i\n 

295: // IDS_SKW0ROUP^E0ARDtN0, ''<Me88age Conteiit>" 

296: // roS_SKWGROUP_PND_JlEOARDING, -<;/Messagp Content*" 

297: if (IpGroup— >hRegarding) 

298: { 

299: LoadString (hCbrdfilelnstance, 

300: IDS_SKWGROUP_REG/VRDING, szField, BUF^LEN); 

301: LoadString (hCardfilelnstance, 

302: IDS_SKWGROUP_END_REGARDING, srtlme, BUF_LEN); 

303: IpBuf - GlobalLock (IpGroup— >hRegarding); 

304: AppendString (IpMessage, szField, 

305: szSpace, IpBuf, szlime, 

306: szRetum, nSize); 

307: GlobalUnlodc (IpOioup— >hRegarding); 

308: } 

309: // Append Delegate msg 

310: if OpGroup— >wF!ag5 & EVENr_FORWARDED 
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311: &St lpGtot^>lpOelegateMsg) 

312: { 

313: LoadSciing (hC&idfilelasiaiice, 

314: IDS_SKWGROUP_STAKr_DELEGArE_MSG, 

315: szFicld, BUF_LEN); 

316: LoadStiiag (hCardfilelastance, 

317: IDS_SKWGROUP_END_DELEGArE_MSG, 

318: BzTime, BUF_J£N); 

319: if (IstrlenOpMessage) 

320: Istrlen (IpGroup— >lpDeIeg?iteMsg) 

321: -I- IstrleQ(szReld) + l8trlen(s^nme) 

322: + 10 < nSizc) 

323: ^jpendString (IpMessage, szFteld, 

324: szSpace, ^pGrotq}— >lpI>elegateMsg, 

325: szTune, szRcturn, nSize); 

326: } 

327: 

328: /• 

329: .^jpeod participant's name 

330: and email address to message body. ^ 

331: V 

332: AppendRedpientlnfo ^Message, IpGroi^, 

333: nSize, nMessageiype); 
334: 

335: /* 

336: ^jpend resource's name 

337: and email address to message body. 

338: •/ 

339: if (nMessageiype 1- MSG_REMINDER) 

340: AppeodReaounxInfo (IpMcssagc, IpGicup, 

341: nSizc, nMessageiype); 
342: 

343: return TRUE; 



344: } 



As its first parameter, the method is passed a pointer to the 
previously-described GROUP_APPOINTMENT data 
structure^--the internal buffer storing context information 
characterizing a group scheduling event (including a 
message-type). At lines 29-37, local (stack) variables are 
declared and initialized. At lines 39-40, the method tests 
whether the message-type involves a resource. For a 
resom-ce, the method wiU load a generic header for the 
message, at line 42. Otherwise (i.e., the "if* statement 
evaluates to "false"), the method will load into the message 
buffer, pointed to by IpMessage, a (non-resource) message 
header, provided that the message-type is Schedule, 
Reminder, Broadcast, or Reschedule. The comment set forth 
at lines 54-107 illustrates an exemplary niessage header. As 
shown, the message header is formatteid in a fashion which 
permits a user having only basic e-mail support to read the 
scheduling message and reply (e.g., accept or decline) 
accordingly. 

After the message header has been loaded into the mes- 
sage buffer, the method proceeds to append to the message 
being constructed the other fields set forth in the previously- 
described message formats. The method proceeds as fol- 
lows. At lines 110-114, the method appends the "message- 
type" delimiter. Tliis is followed by appending the actual 
message type for the message, at lines 116-160. Specifically, 
the method first determines the appropriate text string for the 
message type, at lines 117-158. llien, this message string is 
appended to the message being constructed, at lines 
159^160. 

Other fields of the message can be appended to the 
message being created in a similar manner. At lines 
162-176, the method inserts the original date/time in the 
event that the message is a Reschedule message. At lines 
178-192, the method appends the "from" and "to" date and 
time. At lines at 194-199, the method appends the city and 
country information, and at lines 201-216, the method 
appends location and time zone information. 

At lines 218-225, attribute information is appended. At 
lines 227-234 and at 236-244, the first and second event IDs 



are appended, respectively. In the event that the message 
indicates that the schediiling event has been forwarded (Le., 
delegated) to another user (tested at line 246), the method 

35 appends the sender's name and sender's e-mail address, at 
lines 258-265. Additionally, an "append forward** flag is set, 
at lines 266-271. 

At Hnes 274-291, the method appends the "subject" text. 
Any "regarding" message is appended at lines 293-308, and 

^ any "delegate" message is appended at lines 310-326. To 
complete the message, the participant's name and address is 
appended to the message body, at lines 329-333. Finally, 
resource information (for any resource) is appended to the 
message body, at Hnes 335-341. Now, the message has been 
successfully completed, and the method may return "true" at 

^5 line 343. Once the message has been composed, it can be 
posted to the transport layer, using the previously described 
Schedule__Group_Event Method. 

Receipt of the composed scheduling message by a non- 
SK client without browser support (e.g., WordPerfect Office 

50 user) is illustrated in FIGS. 12A-C. FIG. 12A shows an 
e-mail viewer 1200 displaying the invitation in simple text 
format 1210. Although the message also includes richer 
formats (e.g., Attacbement(s) 1211), the remote system does 
not recognize them and, thus, can simply ignore them. As 
shown in FIG. 12B, the remote user can "reply** to the 
invitation using his or her own e-mail software, as shown at 
dialog 1220, and choose to include the message received 
from the sender, as shown at 1221. Following the instruc- 
tions in the e-mail invitation, the remote user, as shown in 
FIG. 12C, edits the reply 1211fl by entering an "X" in the [ ] 

^ Accept text string at 1213 and entering a brief message 
between the <BEG1N REPLY MESSAGE> and <END 
REPLY MESSAGE> deUmiters or markers 1217. 

The above -illustrated message composition can be 
extended to automatically generate a Hypertext Markup 

65 Language (HTML) form as a scheduling invitation. Here, 
the HTML form is generated in a conventional maimer using 
HTML code, except that instead of a user hand-crafting the 
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fonn, the system automatically maps the scheduling infor- 
mation into appropriate target destinations (fields, buttons, 
and labels) on the form. For instance, the following data 
fields are mapped to HTML fields: 



HIML field 


Mapped infonnation 


Message From: 


{Initiator} 


Date/nme: 


{Date/Tune} 


Duration: 


{Duration} 


Time Zone: 


{Time Zone) 


Location: 


{Location} 


City/Oountry: 


{City} 


Subject: 


{Subject} 


Message: 


{Message} 



10 



15 



Further, the "Accept" and "Decline" responses are mapped 
to HTML buttons. 

Creation of these control in HTML is straightforward. For 
instance, the "Accept" and "Decline" buttons can be emitted 
in HTML format as: 



20 



<im4L> 

<BODY> 

<FORM> 25 

<Hl>Accept and Decline Battons</Hl> 
<INPUTTYPE=**Accepe' VALUE="I accept the invitatton"> 
<INPUTTYPE-*'Dccline" VALUE-"! decline the invitation^ 



46 
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<moDY> 

<;/FORM> 



</HTML> 



Description of the HTML format is well documented in the 
trade literature; see e.g., Duncan, R., A/i HTML Primer, PC 
Magazine, Jun. 13, 1995, pp. 261-270. Further description 
is provided by Duncan, R., Publishing HTML Forms on the 
Web, PC Magazine, Dec. 5, 1995, pp. 391^3. The disclo- 
sures of the foregoing are hereby incorporated by reference. 

Receipt of the composed HTML scheduling message by 
a non-SK client with browser support (e.g., Netscape Navi- 
gator user) is illustrated in FIG. 13. The remote user employs 
the browser 1300 for displaying the invitation in hypertext 
(HTML) format 1310. The scheduling data fields are auto- 
matically placed on the form as HTML form fields 1311. The 
"Accept" and "Decline" buttons, on the other band, are 
placed as buttons 1313. The receiving user can now simply 
respond to the form, whereupon his or her answer is trans- 
mitted back to the sender. 

d. Methodology for Parsing Messages 

Methods of the present invention for identifying and 
processing incoming group scheduling event messages will 
now be described. All incoming mail is initially processed 
by a RcceiveAiUncomingMails method. In an exemplary 
embodiment, this method may be constructed as follows. 



1: 

2: This function will receive all incoming groi^ event messages. 

4: int RcceiveAiUncomingMails (void) 

5: { 

6: LPMESSAGEINFOSET IpInfoSet; 

7: int i, 

8: nLists = cScheduledLists, 

9: nWantDlg=FALSE, 

10: nResult, 

11: nPaint -FALSE, 

12: nFoldeiCreated; 

13: char szSender[PArHMAX+ll szTo[PArHMAX-t-ll 

14: szCC[PArHNAX+ll szBCCfPATHMAX+ll 

15: szSubject[PArHMAX+ll szrime(BUF_LEN+ll 

16: azEmail[65l szEmaa'IVP6[BUF--LEN+ll 

17: 8zAttach[PAIHMAX-fll szSigaatuieEBUF_I£N+l} 

18: HGLOBAL hMessage; 

19: LPSTR IpMesaage; 

20: 

21: IbrnOttFlashSession ( ); 

22: IpMessage - AllocLockBuSer (AhMesaage, NOTETEXTSIZE * 4^ 

23: if(!hMcssagc) 

24: { 

25: HirnOffFlashSession ( ); 

26: return FALSE; 

27: } 
28: 

29: LoadString (hCardfllelnstance, 

30: IDS_SKWGROUP_SIGNArURE, szSignature, 

31: BUF_LEN); 
32: 

33: // Get email messages from Exchange 

34: if (IsDeliverExchange ( )) 

35: { 

36: char szFoldeiName{BUF.U£N-i-l]; 
37: 

38: // ReceiveAllNewMails (hCardfileWnd); 

39: ReceiveAllMailsNow (hCardfileWnd); 
40: 

41: // Create [ntemet Sidekick Folder. 

42: LoadString (hCardfUelnstance, 
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IDS_ISi;_FOLDER_NAME, szFoWeiName, BUF_LEN); 
oFoIdcrCrcatcd 

- CreateAPirstLevelFolderinDe&ultMsgStore 

hChidaieWod, 
szFoklerName 

>; 



// Search for ISK Messages. 
IpIafoSet 

> SearcfaSKWSchcduleMsglnlnboxFolder 

hOrdaieWad, 
szSignatnre 



if (flpInfoSet) // not cnougb memory 

UnlockFreeBiiffeT (hMeasage); 
IbmOSFlashSession ( ); 
return FALSE; 

} 

if (lpliifoSet^>ulQ>unt) 
for (ixO; i<(int)lpInfoSet— >>uloount; fh-) 
if (GetMess&geCbntents (bQirdfileWnd, 



{ 



IpInfoSet— >lpMsg[nfo [illpEID, 
szSendcj, FATHMAX, 
szEmail, 64, 

szEmailiypc, BUF_JLEN, 
szlb, PATHMAX, 
szOC, PATHMAX, 
szSubject, PATHMAX, 
IpMessage, NOHBTEXTSIZE " 4, 
szTune, BUF_LEN, 
szAdacfa, PATHMAX)) 



trim_atart_cnd (szSeader, '\", *\"); 
trimJstarL-end (szSeoder, X\ X'); 
ljim_jtart_end (szEmafl, *V*, 'V'); 
lriin__5lait_cnd (szEmafl, *\", *\")i 
uri]n^stait_end (s^, *Y*, \*)\ 
90: lriin_ptarL_end (s^, *\'\ *\"); 

91: 

92: if (!(nResiilt 

93: • ReceiverMessageHandler (szSeader, 

94: szEmail, szEmaiTiype, 

95: szCX:, szSabject, 

196: IpMessagB, szAttach, 

97: FALSE))) 



nPaint - TRUE; 
SetMailRcad (hardfilcWnd, 

IpIafoSel^>lpMsgInfo{ i].lpEID); 
if (IbLeavcOnScrvcr ( )) 
DeleteMail (hC^rdaieWnd, 

IpInfoSet— >lpMsg[nfc [i]. IpEID, 
TRUE); 

else 
{ 

if (nPolderCreated) 
MovelSKMailslblSKMaflFoider 
{ 

hOirdfileWnd, 

IpInfoSet— >lpMsgInfc[i].lpEID, 
szFoIderName 

} 



} 

FreeMessagelnfoSet (IpIafoSet); 
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// Get email messages from POP3 account 

if (IsDclivcrOwnlntcract ( )) 

{ 

if (SFMailGetNew (hOirdfileWod, szSigDature)) 

if (SFMailBoxOpen ( )) 

IpInfoSet - SFMaUScanMail (hcardfUeWnd); 

if (Ip[nfoSet) 

{ 

for (i-0; i<(iDt)^IiifoSet— >ulCount; i-K-) 

if ( SFGetMessageCbntenU 
{ 

hCardftlcWnd, 

IpInfoSet — >lpMsgIiifG[i].^EID, 
szEmail, 64, 
szScndcr, PATHMAX, 
//szEmaUTVpc, BUF__LEN, 
s^, PATHMAX, 
szCCPATHMAX, 
szBCC, PATHMAX, 
szSubject, PATHMAX, 
lpMc»sagc, NOTETEXTSIZE • 3, 
szAttach, PATHMAX, 
ssOlme, BUF_JLEN 

} 

} 



triin_j5ta]t^&d (szSender, *\", 'V'); 
trim_?tait_end (szSender, V, *\"'); 
trim_*lart_cnd (szEmail, '\", 'V'); 
triin_slarl_end (szEmail, '\"', '\"*); 
triin_start_end (szlb, *V*, *\"); 
tiun_»tait_end (szlb, '\"*, *\"); 

if (l(aResult 

- ReceiverMessageHandler 
{ 

szSende^ 
ftzEmatl, 
szEmain^e, 
szlb, szCC, 
szSubject, IpMessage, 
szAttach. FALSE 

}}} 

continue; 
nPaint » TRUE; 
// delete message from inboz. 
if (nResult) 

SFDeletcMessage 

hOirdfileWnd, 

IpInfoSet— >^MsgInfo [O.IpEID 

}: 

} 

SFMailBoxClose ( ); 



} 



} 
} 

// unlock and free message bkidc 
UnlockFreeBuffer (bMessage); 

TUrnOSFlashSessioD ( ); 

if (qjaint) 

{ 

if (hCoveiPagcWnd && IsOioupPagcFront ( )) 
{ 

Sort_GroupEventList (hCbverPageWnd, NULL, 
Oet_Qmciit_SortFlag ( )); 

if (tnUsts) 

! 

} 

else 

SortGroupEventlnfo (hScheduledList, cScheduledUsts, 
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203: Gct_Curreiit__SoitFlag ( )); 

204: } 

205: letum TRUE; 
206: } 



After initializing local (stack) variables at lines 6-19, the 
method "turns on" the "flash" session, at line 21. This sets 
a global flag for preventing re-entry, since this is a timer/ 
interrupt driven process. At lines 22-27, the method allo- 
cates a memory block for storing an incoming message. If 
the allocation fails, the method returns "false" at line 26. At 
lines 29-r31, the method loads from a resource file the 
signature string (i.e., <1SK>). This string will be used to is 
identify incoming g^oup scheduling events. 

Now, the method is ready to retrieve e-mail messages 
from the user's in-box. At lines 33-121, the method retrieves 
messages for Microsoft Exchange and creates a folder for 
those messages (at lines 41-49). Now, the method searches 20 
in that folder for group scheduling event messages — that is, 
messages containing the identil^ing signature (at lines 
52-58). If at least one group scheduling event message is 
found (i.e., count is greater than zero at line 68), the method 
sets up a "for** loop at line 70, for looping through each such 
message. At lines 72-82, the message contents are extracted 
by a call to GelMessageContents. At lines 85-90, any 
trailing spaces are trimmed from this extracted information. 
As shown, the extracted information includes information 
about the sender (name), e-mail (address), e-mail-type, 
"To", "CC, subject, message, lime, and any attachment. 



Further processing is performed by a call to 
ReceiverMessageHandler, at line 93. The ReceiverMessage- 
Handler method provides appropriate message handling 
(action), based on the extracted or parsed message infonna- 
tion. If the message cannot be handled (i.e., the "if state- 
ment at line 92 evaluates to "false"), then the method loops 
back for the next message, by executing the "continue" 
statement at line 98. Otherwise, the message can be handled 
whereupon the method removes the message from the user's 
in-box (lines 104-106), and places it in a group scheduling 
mail folder (lines 109-115). Thereafter, cleanup is per-* 
formed at line 120. In the event that the user's e-mail system 
is from a P0P3 (Internet Post Office Protocol) account, the 
method executes lines 123-185. Here, the method performs 
essentially the same task as just described for a Microsoft 
Exchange mail account. 

The method completes its operation by freeing up 
memory at lines 187-188, turning off the flash session flag 
at line 190, and repaints the user interface with the new 
information (if needed) at lines 191-204. Thereafter, all 
incoming mail has been appropriately processed, and the 
method may return ''true'* at line 205. 

The message handler itself, ReceiverMessageHandler, 
may be constructed as follows. 



i 



2: His fiincdoa will handle incoming group event messages. 

3: • 

4: int ReceiverMessageHandler (LPSTR IpFrom, 

5: LPSTR IpEraail, 

6: LPSTR IpEmailTVpe, | 

7: LPSTR Iplb, * 

8: LPSTR IpCC, 

9: LPSTR IpSubjcct, 

10: LPSTR IpMessage, 

11: LPSTR IpAttachFilc, 

12: int nReplyCcode) 

13: { 

14: LPSTR IpShortMsg - NULL, IpNew - NULL; 
IS: int aMsgID 

16: - MessageTVpeParser (IpSubject, IpMesaage, &IpNew), 

17: nRcplyiypc - 0; 

18: 

19: if (nMfigID — GROUP_SCHEDULE 
20: 1 1 nMsgID — GROUP_BROADCASr 

21 : II nMsgtD — OROUP__RESCHEDULE) 
22: { 

23: IpShortMsg 

24: ° [sThisAutoReplyMessage OpMessage, 

25: ftnMsglD, 
26: AnReplyiype); 
27: } 
28: 

29: switch (oMsglD) 
30: { 

31: case GROUP_REMINDER: 

32: case OROUP__SCHEDULE: 

33: case GROUP_BROADCAST: 

34: return Handlc_Schedulc__Mccling 

35: { 

36: IpFrom, IpEmail, 

37: IpEmailType, Iplb, 

38: IpOC, IpMessage, 

39: IpAttachFile, oMsglD 

40: }; 

41: 
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42: case GROUP_REPLY: 

43: return Handlc_Rcply 

44: { 

45: IpFrom, IpEmaiJ, 

46: Iplb, JpCC, 

47: IpSubject, IpMessage, 

48: nRepl/rype, IpShoitMsg 

}; 

50: 

51: case GROUP_FREETIME: 

52: return OeateFreeHme.J^tiu^.^ead 

53: { 

54: IpFrom, IpEmaa, 

55: IpCQ IpMessage 

56: }: 

57: 

58: case GROUF_RESCHEDULE: 

59: return HandlcJ^hedule 

.. { 

61: * IpFrom, IpEniail,' 

62: IpEmain>pc. IpTb, 

63: IpCC IpMessage, 

64: nReplyCode 

65: }; 
66: 

67: case GROUP_MEEnNG_Nare: 

68: return HandIc__Mcctuig_Notc 

69: { 

70: IpFrom, IpCC, 

71: IpMessage, IpAttachFile 

72: }; 

73: 

74: caac GROUP_CANCEL_MEEnNG: 

75: return Handle_C^nccLJvfecting (IpFrom, IpCX, IpMessage); 

76: 

77: case GROUP_NEW_RESOURCE: 

78: return Handle_j\ddNewResource (IpFrom, 

79: IpEmail, IpMessage); 

80: 

81: case GROUP_RESOURCE_SCHEDULE: 

82: case GROUP_RESOURCE_RESCHEDULE: 

83: return Handle_Re80urce_3chedule 

84: { 

85: IpFrom, IpEmaU, 

86: IpEmaiTType, Iplb, 

87: IpCX; IpMessage 

88: }; 

89: 

90: case OROUP__RESOURCE_CANCEL: 

91: return Handle_ResourceL_Cuicel (IpFiom, 

92: IpEmail, IpMessage); 

93: 

94: case GROUP_JTIEE_RESOURCE: 

95: return Handle_Free_J^esourcc (IpFrom, tpEmail, ^iMessage); 
96: 

97: case GROUP_TRANSFER»JlESOURCE: 

98: return Handle_Tiansfer^e60urce 

99: { 

100: IpFrom, IpEmaU, 

101: IpEmaiTType, IpMessage, 

302: IpAttachFUe 

103: }; 

104: } 

105: return TRUE; 



106: } 



As shown, the method is invoked with parameters set 
equal to the just-extracted e-mail information. After declar- 
ing local variables at line 14, the method parses out the 
message type, at lines 15-16. At lines 19-21, the method 
examines whether the message is one which it can auto- 
matically reply to; such a condition holds true when the 
message is for a Group Schedule, Broadcast, or Reschedule. 
At lines 20-104, the method establishes a case statement 
which switches on message type or ID, for invoking more 
specialized handlers. Group Reminder, Schedule, and 
Broadcast messages, for instance, invoke a Handle__ 
Schedulc_3(eeting handler at line 34. A group reply 



message, on the other hand, invokes a Handle_Reply han- 
dler at line 43. Other handlers are invoked in a correspond- 
ing manner. A list of exemplary handlers is appended 

60 herewith as Appendix B. 

While the invention is described in some detail with 
specific reference to a single preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 

65 Thus, the true scope of the present invention is not limited 
to any one of the foregoing exemplary embodiments but is 
instead defined by the appended claims. 
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Exemplary Message Fonnats 



Groop schedulmg format design 

1. Internet appointment message format 

Every type of message will have following two parts at leasL 

<Pfoduct Signaturo <ISK>(or <SIS>) 

^Message Typo :« eScheduIe | Broadcast | Reply | Free Time | Reminder | 
Reschedule | Meeting Note | Cancel | Recuiring | New ResoarGe | Resource | Action | 

Synchronization > 
Schedule and Broadcast: 

<Ffom Date Time? :» YY/MM/DD HH:MM 
^ Date Timo :» YY/MM/DD HH:MM 

<Location> Place name where the meeting will be held. 

<Clty> :> City name where the meeting will be held. It is related to Time Zone. 

<Tlme Zone> <lime zone name where appointment time is based ott> 

<AttrLbute6> <Alarm> 

<EventIDl> ' " A unique ID for the cvenL 

<EventID2> :- The second part of the ID. 

<Subject> <Message lext><;/Subject> 

<Mcssagc COntent> <Regatding tcxt>t;/Mc8sagc Contcnt> 

<Participants> "Name; Email address; Email Type" "Name; Email Address; 

Email Type" ^articipanlB> 

<CC> "Name; Email address; Email Type" "Name; Email Address; Email Type" 

<x:c> 

<Room>:» "Name; Email address; Email Typt** "Name; Email Address; Email TVpe" 

</Room> 

<Equ^meQt» "Name; Email address; Email lype** "Name; Email Address; EnnU lype" 
</Equipment> 

If this message ia a broadcast message, it requires no ACCEPT response. 

Reply- 

<Reply T^cs> <Aocept | Dedine | Reschedule Required | Sleep | Forward \ 

Resource I Free Hmo 

<ForwardTo> := <Nam^ E-mail address; Email T^pex/Forwazd Tb> 

« If Reschedule required 

<From Date Time> := YY/MM/DD HH:MM 
<rro Date Time> :- YY/MM/DD HH:MM 

» 

<EventIDl> A unique ID for the eveuL 

<Eveniim> Tbe second part of the ED. 

<Short Message> <Shoit text message>^Short Messag|B> 

«If it b a Reschedule Required, Free Tune Request, or Resource Reservation type of 

Schedule 

There is a file attached on this message 

The Reschedule Required type of reply is for the purpose of rescheduling right away. For 

example, a person received a groi^ meeting request He does not have firee time. So he 

requires to reschedule the meeting with different time. 

The purpose of Sleep type is for people on vacation or leaving. 

Free Time: (A Free Time request message) 

<EvcntIDl> A unique ID for this Free Tune request. 

<EventID2> := The second part of the ID. 

<From Date Tune> :« YY/MM/DD HH:MM 

<To Date Hmo YY/MM/DD HH:MM 

<Subjea> :- <Message tcxt></Subjea> 

This is an auto reply message request. The reply result of Free Tune report is a text matrix 

with 0 and 1. 
Reschedule: 

<Old Dale/nme> :- YY/MM/DD; HH:MM. 

<From Date Time> YY/MM/DD HH:MM 

<ab Date Hmo YY/MM/DD HH:MM 

<Location> > Place name where the meeting wiil be held. 

<City> := City name where the meeting wiil be held. It is related to Time Zone. 

^Hme Zone> ^Time zone name where appointment time is based on> 

<Attributes> > <Alann | Previously Status: Accept; Decline> 

<EventIDl> := A unique ID for the event. 

<EventID2> :« The second part of the ID. 

<Subject> :- <Message text><ySubject> 

^Message Oontent> :- <Regjirding t6Xt></Sub|ect> 

<Participants> :« "Name; EmaU address; Email Type" "Name; EmaQ Address; 
Email iVpc" <;/Paiticipante> 

<CC>:" "Name; Email address; Email TVpc" "Name; Email Address; Email TVpe** 
<JCC> 

<Room> "Name; Email address; Email Type'* "Name; Email Address; Email 

Type" </ 
</Room> 
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Exemplary Message Fonnats 

<Equipineiit> :- "Name; Email address; Email T^pe** ""Name; Email Address; Email 

Typc"</ 

</Equipment> 

If this meeting is previously accepted, then a forced change appointment list will happen, [f 
this meeting is previously declined or not responded, then it is handled like a normal schedule 
requesL 

A Resource request message will be sent agpin when a Reschedule message is sent 
Reminder: 



> YY/MM/DD HH:MM 

> YY/MM/DD HH:MM 

Place name where the meeting will be held. 

Qty name where the meeting will be held. It is related to lime Zone. 

<TIme zone name where appoimment time is based on> 

<Alann |l Previous Status: Accqst; DecUne> 

A unique ID for the event 

Hie second pait of the ID. 

<Message text></Subiect> 

<Regarding text><^Message Conteat> 



"Name; Emafl address; Email l^P^" "Name; Emafl Address; Email 



<From Date 11me> 
<To Date Tuno 
<Locatioa> :» 
<Gty> 
<Tunc Zonc> 
<Attributes> 
<£ventIDl> 
<£ventiD2> 
<Subject> 
<Message ContcDt> 
#if not Broadcast 

<Participants> :» "Name; Email address; Email Type" "Name; Email Address; 

Email l^pe" •^aiticqMntB> 

<CC>:- "Name; Email address; Email T^pc" "Name; Email Address; EmaU TVpc" 

</CC> 
<RDom> 
Type" </ 
</Rooni> 

<Equipment> "Name; Email address; Email Type" "Name; Email Address; Email 

Type" </ 

</Equipment> 

If this meeting is previously accepted, the ACCEPT button will be grayed out if this meeting 
is not re^nded, it is handled like a normal schedule. 
Meeting Note: 

<From Date rune> :- YY/MM/DD HH:MM 
<To Dale Tuno := YY/MM/DD HH:MM 

<Location> := Place oame where the meeting was held 

<City> City name where the meeting will be held. It is related to Time Zone. 

^nme Zone> :- ^FLnc zone name where appointment time is based on> 

<EventIDl> :<> A unique ID for the event 

<EventID2> :- The second part of the ID. 

<Snbiect> := <Mes5age tc3tt></Subjcct> 

<Meeting Note> :» The meeting note text</Meeting Note> 

Cancel a group meeting: 

<EventIDl> := A unique ID for the event 
<EventID2> :- The second part of the ID. 
<Subject> := <Mcssagc (ext><;/Snbject> 
<Short Message> :« <Message textx/Short Message> 
Resource: (Resource Reservation Message) 

<From Date Hmo :- YY/MM/DD HH:MM 

^o Date Tlme> :» YY/MM/DD HH:MM 

<EvcntIDl> :- A unique ID for the event 

<£veniID2> :» The second part of the ID 

<Subject>> :» <Message te3[t>^ubject> 

<Message Contents :- <Regaiding textx/Message Conteiit> 

Schedule a recurring Appointment: 



<Start Date> 
<End Date> 
<From Date Tinie> 
<To Date llme> 
<Recur Pattan 1> 
<Recur Pattern 2> 
<Recur FaUern 3> 
<Ijocation> 
<Qty> :- 
<Time Zone> :- 
<Attributes> :■■ 
<Subject> := 
<Mes8age Content> 



YY/MM/DD 
YY/MM/DD 

YY/MM/DD HH:MM 
YY/MM/DD HH:MM 
Month I ^k I Day 
Frequency 
Include and Exclude 
Place name where the meeting will be held. 

City name where the meeting will be held. It is related to lime Zone. 

^riffle zone name vidiere appointment time is based on> 

<Alarm> 

<Message le3tt></Subject> 
:- <Regaiding textx/Message Content> 



Executing an Action cross the serverleas getworic: 

<From Date Tuno :- YY/MM/DD HH:MM 
<To Date Tuno :«- YY/MM/DD HH:MM 

<Location> Place name where the meeting will be held. 
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Exemplary Message Formats 



<City> City name where the meeting will be held. It is related to lime Zone. 

^rimc Zone> <^nme zone name where appointment time is based on> 

<EventIDl> := A unique ID for the event. 

<EventID2> :- The second part of the ID. 

<Sabject> cMessage te3it></Sttbject> 

<Message Content> :» <Regaiding textx/Message ConteDt> 

<Actton Item> <Java applet | An executable program | operations which can be 

recognized in Sidekick> 

Synchronizing files cross the network: 

<From Date Timo YY/MM/DD HH:MM 

<To Date Tlmo YV/MM/DD HH:MM 

<LDcation> :> Place name where the meeting will be held. 

^ty> :« City name where the meeting will be held. It is related to Tixas Zone. 

<Time Zono :> <'Timc zone name where appointment time is based on> 

<EventIDl> > A unique ID for the event. 

<EventID2> :- The second part of the ID. 

<Subjea> :« <Mcssage tcxt></Subject> 

<Mes8age Content> :- <Regaiding text>-^Me88age 0>ntent> 

<Flle Name» <Flle name which needs to be synchioaized> 

Resource scheduling requires non-overlsqjped time and a subject The sdiedoling is a 

non-negotiable process. The reply only has two options: Accept and Decline. 



APPENDIX B 

Exemplary Message Handlers for Actions 



int Handlc_ScheduIc_Meeting (LPSTR IpFtom, 
LPSm IpEmail, 
LPSTR IpEmailiypej 
LPSTR IpTo, 
LPSTR IpCC, 
LPSTR IpMessage, 
LPSTR ^AttachFUe, 
int nMsgID) 

// This function will scan the incoming message and gpt all the 

// information related to this event. 

// Information includes following parts: 

// - stait date/time and end date/time 

// - time zone 

// - location 

// • City and country 

// - Event properties^ such as alarm, tentative, R5VP. etc.. 

// • Parttdpants info 

// - Resource allocated for this event 

// - Event ID 

// - Subject 

// - Message body 

// After getting the information, it will add one item into Event List 
// 



This function will also handle the RemiiKier and Confinn message type 



} 



retmn TRUE; 



int llandle_jleschedule (LPSTR IpFrom, LPCTR IpEmail, LPSTR IpEmaiTiype, LPSTR 
IpTb, LPSTR IpCC; LPSTR IpMessage, int nReplyCode) 

// This function will scan incoming message and get all the information 
// It will set new value to the same item in the Event database 

} 

****** 

int HandIe_Jlcply (LPSTR IpFrom, LPSTR IpEmaU, LPSTR IpTo, LPSTR IpCC, LPSTR 
4>Subjecl, LPSTR IpMcssage, int olnReplyType, LPSFR IpShortMsg) 

1. Get group schedule information included in IpMessage; 

2. Get Reply type information included in IpMessage; 

3. Handle Group Meeting update, including change recipient status, 
change recipient if it is a forward to type of reply. 
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APPENDIX B-continued 



Exemplary Message Haodlen for Actioas 

} 

int OeateFieeTune31atrijc_Seiid (LPSTR IpFrom, LPSTR IpEmafl, LPSTR IpCX:; LPSTR 

IpMessage) 

{ 

// Create a free time calendar and send to initiator 

) 

r 



int Handlc_>!ccting_Notc (LPSTR IpFrom. LPSTR IpCC, LPSTR IpMcssagc, LPSTR 

IpAttachFQe) 

{ 

// get minutes of meeting and attached file and 
// save to the Event 

} 



/ 

int Handle CaQoel_Meeting (LPSTR IpFrom, LPCTR IpOC; LPSITl IpMessage) 

// get infonnation from message 

// delete event from calendar 

// set current event to canceled status 

} 

« ...............y 

int Handle_Rcsource_Schedulc (LPSTR IpFrom, LPSfTR IpEmail, LFSTR IpEmainVpe^ 

LPSTR IpTb, LPSTR lp(X, LPSTR IpMessage) 

{ 

// get icformadon from message 

// tiy to reserve the resource 

// send reply back to initiator (aooq>t or decline) 

} 



{ 

int Handle__Resource_Cancel (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpMessage) 
// cancel resource reservatbn 

} 

/**•* * 

{ 

int Handlc_Free_Elesoiircc (LPSTR IpFiom, LPSTR IpEmail, LPSTR IpMessagp) 
{ 

// create resource free time calendzu: and send to intiator 

} 



int Handlc_Transfier_Rcsource (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpEmaillVpe, 
LPSTR IpMessage, LPSTR IpAttachFUe) 

// get transfer resource and add an item to event database 

} 



What is claimed is: 50 
1. In a computerized scheduling system, a method for 

assisting a user with scheduling calendar events in an 

electronic calendar, the method comprising: 

(a) receiving input &om the user specifying an event to 
schedule together with a lists of participants desired to S5 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
imable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 60 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 

a plurality of different message formats, each message 
format supporting a different level of information 
content, said plurality of different message formats 65 
selected from a group comprising at least a proprietary 
scheduling format, a Hypertext Markup Language 



(HTML) format, and a simple electronic-mail format so 
that said scheduling invitation may be encoded for 
appropriate processing by disparate remote computer 
systems including those which are unable to interpret 
proprietary scheduling formats of the computerized 
scheduling system of the user; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 
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(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply. 

2. In a computerized scheduling system, a method for 
assisting a user with scbeduhng calendar events in aa 
electronic calendar, the method comprising: 

(a) receiving input &om the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which arc 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system empbyed by said each participant. 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein at least one message format comprises a pro- 
prietary scheduling format of the computerized sched- 
uling system of the user. 

3. The method of claim 2, wherein said message format 
which comprises a proprietary scheduling format of the 
computerized scheduling system of the user is transmitted in 
the electronic scheduling message as a binary attachment. 

4. The method of claim 3, wherein said binary attachment 
comprises a Multipurpose-Intemet-Mail-Extensions binary 
attachment. 

5. The method of claim 1, wherein at least one message 45 
format comprises a simple text message ensuring that a 
participant empbying a computer system providing only 
simple electronic-mail support can reply to said electronic 
scheduling message. 

6. The method of claim 1, wherein said input received 50 
from the user comprises an event time and location. 

7. The method of claim 6, wherein at least one of the 
scheduling replies comprises a reply indicating that a par- 
ticipant cannot participate in the event and further includes 
information indicating an alternate time for scheduling the 
event. 

8. In a computerized scheduling system, a method for 
assisting a tiser with scheduling calendar events in an 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 60 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 55 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 



20 



25 



30 



35 



40 



55 



the event, said scheduling invitation being encoded in 
a plurality of different, message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduUng invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduhng reply, 
automatically updating the calendar based 00 the 
response contained within the scheduling reply, 
wherein said message format which comprises a 
Hypertext Markup Lapguage (HTML) form automati- 
cally generated by the system based on said input from 
the user, said HTML form capable of being viewed by 
any participant having an HTML browser. 

9. The method of claim 8, wherein said HTML form 
comprises form fields displaying said input from the user, 
and further comprises screen buttons whidh a partidpaot can 
select for generating a reply. 

10. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: 

(5) receiving input from the user specifying an event to 
* schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
formal supporting a different level of information coo- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein said a different level of information content 
comprises selected ones of a proprietary scheduling 
format of the computerized scheduling system, a 
Hypertext Markup Language (HTML) format, and a 
simple text format. 

11. The method of claim 1, wherein said electronic 
scheduling invitation includes an embedded identifier which 
is incorporated into each reply so that said computerized 
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scheduliog system can automatically differentiate the replies 
from other electronic mail which the user receives. 

12. The method of claim 11 » wherein said embedded 
identifier includes information allowing said computerized 
scheduling system to automatically identify the replies as 
being associated with a particular electronic scheduling 
invitation. 

13. The method of claim 1, wherein each reply includes, 
a participant identifier allowing said computerized schedul- 
ing system to automatically associate each reply with a 
particular participant. 

14. The method of claim 13, wherein step (e) includes 
indicating in the calendar which participants can attend. 

15. The method of claim 1, wherein step (c) includes: 
transmitting said scheduling invitation via a particular 

electronic-mail format of America On-line, 
CompuServe, Microsoft Exchange, and Intcmet P0P3, 
wherein the particular electronic-mail format einployed 
is selected based on an electronic-mail address for each 
participant 

16. An automated electrotuc scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
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electronic scheduling system, said plurality formats ^ event 



a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
wherein said formats comprise at least a simple text 
message understood by any participant having a system 
with simple e-mail support, a Hypertext Markup Lan^ 
guage (HTML) form understood by any participant 
having a system with an Internet browser, and a binary 
attachment understood by any participant having the 
automated electronic scheduling system. 

22. The system of claim 21, wherein said simple text 
message includes delimiters for recording a desired partici- 
pant's response in a manner whidi can be identified by the 
parser. 

23. The system of claim 22, wherein said delimiters 
comprise text stringis having a form substantially like [ ] 
Accept and [ ] Decline, for allowing a desired participant to 
indicate whether the participant can attend the particular 



selected from a group comprising at least a proprietary 
scheduling format, a Hypertext Markup Language 
(HTML) format, and a simple electronic-mail format so 
that said e-mail invitation may be encoded for appro- 
priate processing by disparate e-mail systems including 
those which are unable to interpret proprietary sched- 
uling formats of said automated electronic scheduling 
system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each cfcsired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event. 

17. The system of claim 16, further comprising: 

a calendar update module for automatically indicating 
which desired participants can attend the particular 
event 

18. The system of claim 16, wherein said composer inserts 
an identifier into the e-mail invitation so that any reply 
which incorporates contents of the e-mail invitation can be 
associated with the particular event. 

19. The system of claim 18, wherein said identifier is 
inserted into a subject line of the e-mail invitation. 

20. The system of claim 16, wherein said composer inserts 
into the e-mail invitation for each particular desired partici- 
pant an identifier for the participant so that any reply which 
incorporates contents of the e-mail invitation can be asso- 
ciated with the particular desired participant 

21. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 



40 



45 



50 



55 



60 



65 



24. The system of claim 22, wherein said delimiters fur- 
ther comprise text strings having a form substantially like 
<BEGIN REPLY MESSAGE> and <END REPLY 
MESSAGE>, for allowing a desired participant to enter a 
reply which is automatically recognized and processed by 
the system. 

25. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
wherein said e-mail transport mechanism is a selected 
one of a Microsoft MAPI (Messaging Application 
Programming Interface) compliant e-mail transport 
mechanism and a POP3 (Internet Post OfBce Protocol) 
compliant e-mail transport mechanism. 

26. A method for unattended scheduling of resources, the 
method comprising: 

storing in a computer information describing a set of 
resources which are available for use by individuals; 

providing at least one electronic mail (e-mail) account at 
the computer for receiving e-mail scheduling requests 
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from the individuals for scheduling use of the resources 30. The method of claim 2% wherein said movable type 

at particular times; of resource includes an "equipment" resource type. 

for such an e-mail request received at the computer, 31. The method ofclaim 29, wherein said immovable type 

processing the e-mail request for identifymg a particu- ^ • , . « « 

lar individual who is requesting a particular resource at 5 of resource mcludes a room resource type, 

a requested time; 32. The method of claim 31, wherein said scheduling 

comparing the received request against a scheduling cal- calendar also maintains schedules for meetings of the indi- 

endar listing availability of the particular resource at viduals and wherein individuals are not allowed to schedule 

the requested time; and meetings which require an identical resource which is of 

if the particular resource is available at the requested time, , „ ». 

* ^ 11 J- 1 -1 * 10 ^6 room, 
automatically sending a reply e-mail message to the 

particular individual confirming acceptance of the ^3. The method of claim 29, wherein a resource which is 

scheduUng request and updating the scheduling calen- immovable is not allowed to accept scheduling requests 

dar for indicating that the particular resource is now specifying times which overlap. 

scheduled at the requested time for use by the particular 34 -y^^ method of claim 29, wherein a resource which is 

inuividudl 

-^T-m. *iljri- CL movable is allowed to accept scheduling requests specifying 

27. The method of claim 26, further compnsmg: . h'nhi r j s> 
,if the particular resource is unavailable at the requested ti^nes w overap. 

time, automatically sending a reply e-mail message to method ofclaim 26, wherein said processing the 

the particular individual denying acceptance of the e-mail request includes parsing the e-mail request to extract 

scheduling request. 20 an identifier indicating that the e-mail is a scheduling request 

28. The method of claim 27, wherein said reply e-mail for a resource. 

message further comprises a report indicating availability of ir _ j * 1 • 1^ u • -j * j 

the paSicular resource for a given time perk>d. . 26. wherem said requested tmie 

29. The method of claim 26, wherein said set of resources automatically converted by the system to a tme zone 
include at least two types of resources selected &om a 25 ^'^itive to where the particular individual resides, 
movable type of resource and an im[iK>vable type of 

resource. » ♦ ♦ ♦ * 



I 
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